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

From: Eric Rescorla <[email-masked]>
Date: 31 May 2001 21:19:26 -0700

Shiho MORIAI <[email-masked]> writes:
> Our proposal also gives a new option, an efficient 128-bit block
> cipher that is royalty-free!  Since the only such cipher currently
> available is AES, our actions with regard to Camellia should be well
> received.
On what basis do you say this? Twofish, Serpent and MARS are all
fast, 128-bit ciphers which are royalty free.

-Ekr

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: 31 May 2001 21:23:43 -0700

Shiho MORIAI <[email-masked]> writes:
> >We don't believe that proprietary algorithms should be added to the TLS
> >standard.
> 
> I agree with you on that point. So we have decided to grant royalty-free
> licenses for the essential patents of Camellia.
Is the intellectual property statement for it up yet? I don't
see it on the IETF site.

-Ekr

---

---

From: Shiho MORIAI <[email-masked]>
Date: Fri, 01 Jun 2001 13:38:47 JST

Eric, 

I mean the only such cipher currently available defined (or proposed)
for TLS is AES. 

I know Twofish, Serpent and MARS are all fast, 128-bit ciphers which
are royalty free.  Camellia is faster than Serpent in software
implementation on many platforms.  Moreover, Camellia has the
advantage of small hardware over Twofish and MARS.

Shiho

---

---

From: Shiho MORIAI <[email-masked]>
Date: Fri, 01 Jun 2001 13:49:05 JST

Eric, 

I sent a formal patent statement pertaining to Camellia to the IETF
Secretariat by air mail last week. I don't know when it will be
available on the IETF page of IPR Notices, so I'll put it on the
Camellia home page soon. 
http://info.isl.ntt.co.jp/camellia/

Shiho

---

---

From: Eric Rescorla <[email-masked]>
Date: 31 May 2001 22:20:58 -0700

> I mean the only such cipher currently available defined (or proposed)
Sure, but this is largely because people have only felt the
need for one such [fast, 128-bit, royalty free] cipher, not
because no others are available. If the WG consensus is that
we need another, the other AES candidates would be the obvious
choices.

-Ekr

[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/

---

---

From: Hironobu SUZUKI <[email-masked]>
Date: Sat, 02 Jun 2001 16:19:57 +0900

Eric said:

> If the WG consensus is that we need another, the other AES
> candidates would be the obvious choices.

I understand your opinion.

We may select 2 ciphers from AES candidates, Serpent and Twofish,
because those ciphers are secure and have free license. So, we may use
GPL lisenced source codes of Serpent and Twofish.

But I guess many cryptographers never select MARS and RC6.  I show 2
data which came from the NIST's survey of 3rd AES confernece.

SHOULD AES

http://h2np.net/hironobu/docs/AESSea2000July3.files/v3_slide0013_image009.gif

SHOULD NOT AES

http://h2np.net/hironobu/docs/AESSea2000July3.files/v3_slide0014_image010.gif

I like Serpent but Serpent is too slow under small network computers
like a PDA.  Twofish is a good cipher but nobody proposed to TLS WG
yet.

Cemellia is a good cipher for TLS too.

Camellia is newer than other AES candidates. But it's bulit on E2 and
MISTY technologies. E2 was one of AES candidates and has no
vulnerability.  MISTY was developed by Mituru Matsui who is well known
as a developer of Liner Crypto Analysis and the first DES breaker.

Camellia is a AES style cipher, a very secure, fast and small S/H
implementation.
   
Some advantage of Camellia as below

  Flexible:  Choice small or fast for software implementation.
  Fast:	     As fast as Twofish.
  Small S/W: Better than any AES finalist with resonable speed.
  Small H/W: Better than any AES finalist.

Twofish is a good cipher.  Camellia is a good cipher too and has some
advantages.

-- 
Hironobu SUZUKI        Independent Software Consultant
E-Mail: [email-masked]
URL: http://www.pp.iij4u.or.jp/~h2np/
URL: http://h2np.net

---

---

From: Eric Rescorla <[email-masked]>
Date: 02 Jun 2001 08:24:54 -0700

> data which came from the NIST's survey of 3rd AES confernece.
Presumably this argument applies a fortiori to Camellia, since
it's predecessor, E2, didn't even make it to the final five.

> like a PDA.  Twofish is a good cipher but nobody proposed to TLS WG
That's easily fixed.

I suspect that the reason for this is that it's widely
believed that we don't need another AES-style cipher in TLS,
not that Twofish is considered unacceptable.

I'm not convinced that we need another AES-style cipher in TLS,
since we have 3DES as a fallback. If you want to argue that we
need another one, then that's fine. However, this is not a
particularly strong argument for Camellia since other ciphers
are rather more obvious choices.

-Ekr

---

---

From: Hironobu SUZUKI <[email-masked]>
Date: Sun, 03 Jun 2001 14:42:43 +0900

> Presumably this argument applies a fortiori to Camellia, since it's
> predecessor, E2, didn't even make it to the final five.

Technically, many cryptographers have thought that E2 has more
security margin than MARS or RC6, but it's true that E2 is slower than
other finalists except Serpent.  From my point of view, MARS is a ill
designed cipher and RC6 is too small security margin.

> since we have 3DES as a fallback.

Your opinion sounds a sort of backward-looking way of thinking.  I'm
thinking that AES, I mean Rijndael, should be as a fallback
cipher. Camellia for TLS is worth considering(and Twofish also).

---

---

From: Eric Rescorla <[email-masked]>
Date: 03 Jun 2001 20:56:16 -0700

Hironobu SUZUKI <[email-masked]> writes:
> cipher.
Could you please clarify this? As far as I can tell, the intention
is that AES will be the stadard block cipher for TLS (replacing
3DES).

>  Camellia for TLS is worth considering(and Twofish also).
Why? The reason for adding AES is that 3DES is too slow.
AES fills the niche of a fast block cipher quite well.
Why is there a need to add Twofish, Camellia, or any other
cipher that fills the same niche as AES?

-Ekr

---

---

From: David Blaker <[email-masked]>
Date: Mon, 4 Jun 2001 08:18:21 -0400

I concur with Eric. Our company builds high-performance network security
processors. I realize it has always been the ietf's policy to disregard
hardware issues and only worry about software issues. However, as a
practical matter, SSL/TLS is increasingly used with hardware acceleration at
the server end. Proliferating cipher suites are impractical for ASIC
development. We see no need for any additional encryption beyond AES with
3DES as a fallback.
_________________________________________
David Blaker, CTO
NetOctave, Inc.
P.O. Box 14824
Research Triangle Park, NC 27709
Phone (919) 463-9903 x.206 / Fax (919) 463-9905
email mailto:[email-masked]
website http://www.netoctave.com

-----Original Message-----
From: Eric Rescorla [mailto:[email-masked]]
Sent: Sunday, June 03, 2001 11:56 PM
To: IETF Transport Layer Security WG
Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt

-Ekr

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---

---

From: Shiho MORIAI <[email-masked]>
Date: Tue, 05 Jun 2001 00:12:06 JST

On Mon, 4 Jun 2001, at 08:18:21 -0400,
David Blaker <[email-masked]> wrote:

>hardware issues and only worry about software issues. 

Your comment is to the point. "Don't ignore hardware" says Mitsuru
Matsui, who is one of the designers of Camellia and also participated
in designing KASUMI, the 3GPP standard cipher for confidentiality and
authentication.

>However, as a practical matter, SSL/TLS is increasingly used with
>hardware acceleration at the server end. Proliferating cipher suites
>are impractical for ASIC development. We see no need for any
>additional encryption beyond AES with 3DES as a fallback.

A distinguishing feature of Camellia is its small hardware design.
The hardware design, which includes the parts for key schedule,
encryption and decryption, occupies only 9.66K gates using a 0.35um
CMOS ASIC library, which is in the smallest class among all existing
128-bit block ciphers.

So, addition of camellia cipher suites will be allowable from hardware
viewpoint.

I don't know why most of the new ciphersuites are rejected.  It is
meaningful to adopt new designs and results based on progress in
cryptgraphic techniques and research, isn't it?  Is it so difficult to
add them as options?  Some people need RSA-OAEP, and others need
Camellia.  I hear that some TLS products with Camellia are being
developed.  Camellia is also proposed as one of the cryptographic
techniques to be used in the electronic government system of Japan. 
Japanese government has no choice but AES or slow 3DES or other
patented bulk ciphers?

Shiho

---

---

From: Eric Rescorla <[email-masked]>
Date: 04 Jun 2001 08:27:11 -0700

Shiho MORIAI <[email-masked]> writes:
> Some people need RSA-OAEP, and others need
> Camellia. 
I don't hear much of a groundswell that we NEED OAEP either.

> I hear that some TLS products with Camellia are being
What's wrong with AES that you would need something else?

-Ekr

---

---

From: David Hopwood <[email-masked]>
Date: Mon, 04 Jun 2001 16:08:06 +0100

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

> A distinguishing feature of Camellia is its small hardware design.

If Camellia ciphersuites are added then hardware will have to implement
*both* Camellia and AES (possibly also 3DES and RC4). So small size in
hardware is not a valid reason to add any new ciphersuites.

> I don't know why most of the new ciphersuites are rejected.

Complexity. All else being equal, a standard with fewer ciphersuites is
a simpler standard, both from the point of view of security analysis, and
of implementation.

> It is meaningful to adopt new designs and results based on progress in
> add them as options?  Some people need RSA-OAEP,

No-one needs RSA-OAEP. As I've pointed out, it has no security advantages
over the current ciphersuites with the RFC 2246 fix.

> and others need

As are AES and 3DES, according to the CRYPTREC pages
(http://www.ipa.go.jp/security/enc/CRYPTREC/index-e.html).

> Japanese government has no choice but AES or slow 3DES or other

and RC4. Why is that insufficient choice? Adding more symmetric ciphers
will do nothing to improve the security or practicality of TLS. There are
more important changes that would improve security (for instance to ensure
that a strong ciphersuite with forward secrecy will be negotiated in as
many cases as possible - i.e. except when talking to an "old" peer
implementation that doesn't support any such ciphersuite).

- -- 
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: Win Treese <[email-masked]>
Date: Mon, 04 Jun 2001 17:23:46 -0400

First, I don't hear a consensus (rough or otherwise) for advancing the
Camellia ciphersuite specification for TLS as a Proposed Standard.

Given that, are there implementers out there who want to include
Camellia in interoperable TLS implementations? If so, should the draft
be published as an Informational RFC to reserve ciphersuite
identifiers?

(Note for those who may recall earlier discussions about ciphersuites:
the IANA isn't going to register them, so it falls to the working
group.)

Win Treese
Chair, TLS Working Group
[email-masked]

---

---

From: Peter W <[email-masked]>
Date: Mon, 4 Jun 2001 21:03:52 -0400

On Tue, Jun 05, 2001 at 09:42:12AM +0900, Hironobu SUZUKI wrote:
> 
> > Why is there a need to add Twofish, Camellia, or any other cipher
> > that fills the same niche as AES?
> 
> I'm thinking for the expanding reliability of TLS for the
> future. Also, I'm thinking about better security for TLS users.

I think David Hopwood said this best: all things being equal, 
simple is better than complex. If neither Camellia nor RSA-OAEP
offer significant benefits (e.g., address needs or desires unmet
by other ciphers), then adding them is a bad idea.

-Peter

---

---

From: Hironobu SUZUKI <[email-masked]>
Date: Tue, 05 Jun 2001 09:42:12 +0900

---

---

From: Eric Rescorla <[email-masked]>
Date: 04 Jun 2001 18:06:44 -0700

> future. Also, I'm thinking about better security for TLS users.
These are both laudable goals but I fail to see how adding
more cipher suites achieves them.

-Ekr

---

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 5 Jun 2001 13:31:15 +0200

> a simpler standard, both from the point of view of security analysis, and

Also, with TLS as it is now, ciphersuite numbers would pretty soon be
scarce if every symmetric cipher is combined with every key exchange
method.

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

---

---

From: Dr S N Henson <[email-masked]>
Date: Tue, 05 Jun 2001 12:50:51 +0100

> scarce if every symmetric cipher is combined with every key exchange

I liked the idea you(?) proposed a while ago of using OIDs for other
cipher suites through the proposed extension mechanism. 

I've lost count of the number of times someone has asked about how to
use some weird cipher/digest combination (blowfish is often asked about)
or indeed some not so weird combination that is not present in any of
the official specs: e.g. DSA with no encryption, RSA+ephemeral DH+RC4 or
anonymous RSA.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [email-masked] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [email-masked] PGP key: via homepage.

---

---

From: Hiroki Ueda <[email-masked]>
Date: 06 Jun 2001 08:47:42 +0900

> be published as an Informational RFC to reserve ciphersuite

Currently we are implementing an interoperable TLS module
including Camellia, by reference to draft-ietf-tls-camellia-01.txt.

-- Hiroki Ueda / NTT Labs, JAPAN.
-- Je le vois, mais je ne le crois pas!

---

---

From: Hiroki Ueda <[email-masked]>
Date: 06 Jun 2001 09:21:44 +0900

> scarce if every symmetric cipher is combined with every key exchange

What does this word "every" mean?
If it means *ALL* (algorithms that ever constructed
and that someone will construct), your mention is true.

---

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 7 Jun 2001 11:23:26 +0200

> and that someone will construct), your mention is true.

I meant every symmetric cipher specified for use with TLS and every
key exchange method specified for use with TLS.

Occasionally new ciphersuites for new symmetric ciphers are proposed
(e.g. a couple of AES ciphersuites, a couple of Camellia
ciphersuites), and occasionally new ciphersuites for new key exchange
methods are proposed (e.g. Kerberos, SRP, ECC).  As negotiation of
these ciphersuite aspects is not orthogonal, if all of these new
ciphersuites were accepted, it would be natural to define a bunch of
additional ciphersuites for Kerberos key exchange with Camellia
encryption, SRP key exchange with Camellia encryption, elliptic curve
key exchange with Camellia encryption, and so on.

And if someone does not like SHA-1, we can repeat the same game for
MACs.

---

---

From: Bill Yeager <[email-masked]>
Date: Mon, 11 Jun 2001 13:34:10 -0700 (PDT)

Hello Win,

I am writing you a note in support of advancing the Camellia ciphersuite
specification for TLS as a proposed standard. I have many reasons, but will be
brief:

	1) I am the owner of the Project JXTA security project (www.jxta.org) 
	which is the Sun opensource, peer-to-peer project. As such, I am 
	planning on adding the Camellia ciphersuite to our own ciphersuites for
	peer-to-peer, secure communication. 

	Our final implemenation will be "almost TLS" as specified in rfc2246 
	with the "p2p twist" that every client is also a server, and vice-versa.
	As opensource, we cannot, and will not limit the addition of new 
	ciphersuites to our TLS-like implementation.
 
	If you are interested in more details, please let me know.

	2) The addition of the Camellia suites to Project JXTA is motivated by 
	
	  a) Camellia's high level of security.
	
	  b) the *high probability* that Camellia will become widely deployed in 
	  mobile phones and smartcards, the former beginning with I-mode, and 
	  the latter because of its hardware design which minimizes gate 
	  requirements. 

	  These small devices are perfect candidates to widely deploy p2p
	  technology on 2.5 and 3G wireless networks.

Thus, targetting TLS for small devices will become extremely important over
the next several years. This is where most of the internet's secure
communications will take place given even the most modest predictions for
mobile device deployment during this time. Thus, I believe it is extremely
important at this time to make sure we do not limit our choices with respect
to the ciphersuites that TLS offers. 

Our goal must be to motivate, and encourage the use of TLS, and thus internet
security.  I've often said that the recent ".com super nova" is really the
"big bang" of the internet. 

It is the real beginning for e-commerce. The internet is restructuring itself,
using the free energy released in that super nova. The activity at its core is
huge, we are all part of it, and have as an obligation, to both welcome and
embrace new technologies which have at their base superior engineering. This
surely includes ciphersuites like Camellia.

Thank you very much for considering my comments,

Bill Yeager
Senior Software Architect
Project JXTA
Sun Microsystems, Incorporated

---

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 12 Jun 2001 0:58:04 EDT

Bill:

I'm also very interested in JXTA, especially its core protocols and
security issues.  However, I must take issue with the premise that
because JXTA is open-source (how is an IETF protocol closed?) it must
allow any and every bad combination of algorithms to be combined into
a cipher suite.  Not only does that weaken the security of the system,
but it also hampers interoperability between peers AND increases the
size of the code base that must be implemented to ensure minimum
interoperability requirements.  

IETF working groups produce open standards.  I strongly believe that
the JXTA core protocols should follow the IETF standards process.  The
JXTA core protocols define a peer to peer network that in a real sense
replaces the original p2p network (IP4) which has been torn apart over
the last decade by dynamic addressing, firewalls, and address
translation.  If the network for the decades to come might be JXTA,
then it should benefit from the experience and review that an IETF
working can bring to it.

- Jeff

> You are currently subscribed to ietf-tls as: [email-masked]

 Jeffrey Altman * Sr.Software Designer      C-Kermit 7.1 Alpha available
 The Kermit Project @ Columbia University   includes Secure Telnet and FTP
 http://www.kermit-project.org/             using Kerberos, SRP, and 
 [email-masked]          OpenSSL.  SSH soon to follow.

---

---

From: Pete Chown <[email-masked]>
Date: Tue, 12 Jun 2001 11:48:39 +0100

> with the "p2p twist" that every client is also a server, and

It's not really the question you were asking, but I'm curious to know
what you mean by "almost TLS".  Do you just mean that each machine
will be a TLS client and server at the same time (for different
connections of course)?  Alternatively will you actually be changing
the protocol?

-- 
Pete

---

---

From: Bill Yeager <[email-masked]>
Date: Tue, 12 Jun 2001 14:30:01 -0700 (PDT)

Hi Jeff,

| However, I must take issue with the premise that
| because JXTA is open-source (how is an IETF protocol closed?) it must
| allow any and every bad combination of algorithms to be combined into
| a cipher suite.

Are you saying that Camellia is bad? I don't think so (-: Open Source has
review just like the IETF, and certainly (maybe I was not precise enough in my
statement), we'd review the technical merits of a cipher suite before
permitting it to be used. I think Camellia qualifies here. And, for the
current set of clients, we are very small with respect to the suites we
support. I had to put something together in about six weeks, and am looking
for volunteers to add more suites (-: Right now I only have RSA(512 bit),
RC4(160bit), MD5, and SHA-1 + MAC + digital signature + a very good PRNG based
on SHA-1. Currently all in Java and surprisingly fast! Volunteers appreciated.

| increases the
| size of the code base that must be implemented to ensure minimum
| interoperability requirements.

This is an important consideration, and well taken. Still, I am thinking when
p2p or TLS move to mobile phones(SSL is already there for java - 64K byte
implementation called KSSL), the clients will have support for a very small
set of crypto suites as demanded by the footprint of these devices, and this
will either be pretty much carrier/manufacturer controlled, or an agreed upon
subset maybe arbitrated through, dare I say, ETSI. And, some of this will be
offloaded to SIM cards.

A cool thing about Java on these devices is that one can download a jar on the
live network, and update or replace the classes. This creates lots of
interesting possibilities ...

| IETF working groups produce open standards.  I strongly believe that
| the JXTA core protocols should follow the IETF standards process.

You will not find me disagreeing with you here. This has been discussed in our
group from the very beginning. For me, it has always been difficult to decide
when something has been sufficiently tested, and well enough understood, to
move it to a draft-rfc. We have our initial specification. I don't say any
reason why the next specification cannot be submitted as a draft-rfc. It is
foolish not to take advantage of the intellectual input one will get in the
IETF. Any volunteers out there? 

| If the network for the decades to come might be JXTA,
| then it should benefit from the experience and review that an IETF
| working can bring to it.

100% correct. Except, that I would say, "If the network for the decades to
come might be *something like* JXTA ... ." And, this might be what is required
to motivate a fully deployed IPV6! This will simplify the p2p world
tremendously given:

| define a peer to peer network that in a real sense
| replaces the original p2p network (IP4) which has been torn apart over
| the last decade by dynamic addressing, firewalls, and address
| translation.

Sigh ... lots to do for sure.

Bill

---

---

From: Eric Rescorla <[email-masked]>
Date: 12 Jun 2001 14:45:11 -0700

> 	ciphersuites to our TLS-like implementation.
Really? So we should be expecting you to implement 
TLS_FIXED_KEY_WITH_ROT13_SHA real soon now? 

Neither open source implementations nor open source standards need
to implement every single algorithm that anyone suggests.

> It is the real beginning for e-commerce. The internet is
> restructuring itself, using the free energy released in that super
> nova. The activity at its core is huge, we are all part of it, and
> have as an obligation, to both welcome and embrace new technologies
> which have at their base superior engineering. This surely includes
> ciphersuites like Camellia.
It has yet to be established that Camellia is superior engineering or
technology. Rather, it's a relatively new algorithm that has seen
comparatively little analysis or review.

Yes, it was designed by some big names, and yes it looks good on the
surface, but such algorithms have turned out to be flawed
before. Surely, to the extent to which we have an obligation it
includes not basing a Proposed Standard on such an untried algorithm.

I don't have a problem with a Camellia draft going to Informational
or Experimental. This would provide a cipher suite number and
an archival reference. Why do you believe it needs to go to Proposed
instead?

-Ekr

---

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 12 Jun 2001 17:47:00 EDT

> Are you saying that Camellia is bad? I don't think so (-: 

I certainly am not saying that Camellia is bad.  I do not make the
claim under any circumstances to state whether or not a particular
cipher is good or bad.  I don't have the expertise.

> Open Source has review just like the IETF, and certainly (maybe I
> was not precise enough in my statement), we'd review the technical
> merits of a cipher suite before permitting it to be used. I think
> Camellia qualifies here. And, for the current set of clients, we are
> very small with respect to the suites we support. I had to put
> something together in about six weeks, and am looking for volunteers
> to add more suites (-: Right now I only have RSA(512 bit),
> RC4(160bit), MD5, and SHA-1 + MAC + digital signature + a very good
> PRNG based on SHA-1. Currently all in Java and surprisingly fast!
> Volunteers appreciated.

I did not say that Open Source did not have review.  

> subset maybe arbitrated through, dare I say, ETSI. And, some of this will be

And the easiest way to reduce the footprint size is to reduce the
number of ciphers.  So if you figure that there is going to be one
cipher implemented it will most likely be AES.

My guess is that these mobile devices are going to need to support not
just JXTA p2p security protocols, but TLS, and maybe even several
other protocols.  It is extremely important that a small common set of
ciphers suites be used across the board.  This is the same nail 
that Russ Housley has been trying to hammer home in the Security Area
over the last year.

> A cool thing about Java on these devices is that one can download a
> jar on the live network, and update or replace the classes. This
> creates lots of interesting possibilities ...
 
Absolutely.  That is way makes dynamic programming so much fun.
Unfortunately, the ability to download updated JARs does nothing to
increase the available space.

> You will not find me disagreeing with you here. This has been
> discussed in our group from the very beginning. For me, it has
> always been difficult to decide when something has been sufficiently
> tested, and well enough understood, to move it to a draft-rfc. We
> have our initial specification. I don't say any reason why the next
> specification cannot be submitted as a draft-rfc. It is foolish not
> to take advantage of the intellectual input one will get in the

Basicly, as soon as you are ready to write a published spec, you
should submit it as an I-D.  Then we can request a BOF for the next
IETF meeting to form the actually working group.  Although, in this
case we can probably bypass the BOF due to the demonstrated interest
in JXTA.

I am happy to assist in the editing of I-Ds and working for form the
necessary working groups to take the JXTA Core protocols into the IETF
space.

- Jeff

---

---

From: Bill Yeager <[email-masked]>
Date: Tue, 12 Jun 2001 14:50:58 -0700 (PDT)

Hi Ekr,

| It has yet to be established that Camellia is superior engineering or
| technology. Rather, it's a relatively new algorithm that has seen
| comparatively little analysis or review.

Are you certain about "comparatively little?" I defer to Shiho on this one (-:

| I don't have a problem with a Camellia draft going to Informational
| or Experimental. This would provide a cipher suite number and
| an archival reference. Why do you believe it needs to go to Proposed
| instead?

I would like your group to do what is appropriate within its guidelines. I
simply did not want to see Camellia stalled. I think in the end that would be
regrettable. Experimental or Informational is fine by me.

Thanks for you note,

Bill

---

---

From: Bill Yeager <[email-masked]>
Date: Tue, 12 Jun 2001 15:03:25 -0700 (PDT)

| And the easiest way to reduce the footprint size is to reduce the
| number of ciphers.  So if you figure that there is going to be one
| cipher implemented it will most likely be AES.

Rijndael might be the one. This really depends on deployment as you know. I
still like choice. I forget the comparison Rijndael's gate density wrt
Camellia. Let's revisit this in 2005 (-: 

| It is extremely important that a small common set of
| ciphers suites be used across the board.  This is the same nail 
| that Russ Housley has been trying to hammer home in the Security Area
| over the last year.

Easy to say. More difficult to coerce. I like natural selection ...

| Absolutely.  That is way makes dynamic programming so much fun.
| Unfortunately, the ability to download updated JARs does nothing to
| increase the available space.

Not necessarily. It cannot reduce the absolute space available, but might
reduce the relative amount of space given a better implementation, etc ... IT
does permit experimentation. 

| Basicly, as soon as you are ready to write a published spec, you
| should submit it as an I-D.  Then we can request a BOF for the next
| IETF meeting to form the actually working group.  Although, in this
| case we can probably bypass the BOF due to the demonstrated interest
| in JXTA.
| 
| I am happy to assist in the editing of I-Ds and working for form the
| necessary working groups to take the JXTA Core protocols into the IETF
| space.

Thanks Jeff. We'll see about this Fall. More free time then (I hope).

Bill

---

---

From: Eric Rescorla <[email-masked]>
Date: 12 Jun 2001 15:19:17 -0700

> Are you certain about "comparatively little?" I defer to Shiho on this one (-:
Compared to AES. Definitely.

-Ekr

---

---

From: Ben Laurie <[email-masked]>
Date: Wed, 13 Jun 2001 09:03:07 +0100

> interesting possibilities ...

Many of them rather scary, IMO! Plus, I'm sure JXTA is supposed to be
language independent. Or is that just a sop?

> IETF. Any volunteers out there?

Sure. BTW, it seems to me that you should be looking at the MANET stuff
(http://www.ietf.org/html.charters/manet-charter.html).

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 13 Jun 2001 8:39:19 EDT

> language independent. Or is that just a sop?

It is not just a sop.  To ensure that JXTA is language independent is
one of the reasons that I want to move the core protocols into the
IETF and out of the JXTA community.  The IETF is strictly a language
independent wire protocol community.  Sure we sometimes get ourselves
into the API business but it is a rarity.  For JXTA to be a success,
the protocols cannot be developed based upon the implementation
experience of one language/technology platform.

---