Subject: [Uta] On cipher suites with Camellia of TLS-BCP

From: Kohei Kasamatsu <[email-masked]>
Date: Thu, 11 Sep 2014 19:42:47 +0900

Hi, Stephen and UTA folks

Thanks Stephen for your comments.
I agree with your comments and will not discuss alternative algorithms
in UTA WG.
I would like to discuss alternative algorithms in a suitable group.

However, by reason of followings, I wish cipher suites with Camellia are
also expressed in TLS-BCP, meanwhile I do NOT care about description of
enforcement statements; i.e., recommended, or optional.

First, I strongly believe that status of Camellia is different from any
other symmetric ciphers (including Chacha20).
For example, Camellia is only selected as recommended symmetric cipher
together with AES in NESSIE project [1].
And, it also standardized in ISO/IEC18033-3 [2], ITU-T, W3C, and so on.

>From the above, Camellia is widely approved by global organizations.
Actually, it is recommended by "Algorithms, Key Sizes and Parameters
Report"[3] of ENISA (page59) as follows:
---
Looking at the record layer protocol (i.e. the algorithms to encrypt the
actual data), we see that only the use of Camellia and AES are
recommended within a mode such as GCM or CCM.

  (snip)

This means at the time of writing we would only recommend the following
cipher suites, for future use within TLS
  *_WITH_Camellia\index{Camellia}_128_GCM_SHA256,
  *_WITH_AES_128_GCM_SHA256,
  *_WITH_Camellia\index{Camellia}_256_GCM_SHA384,
  *_WITH_AES_256_GCM_SHA384,
  *_WITH_AES_128_CCM,
  *_WITH_AES_128_CCM_8,
  *_WITH_AES_256_CCM,
  *_WITH_AES_256_CCM_8.
where * is sux denoting the underlying key exchange primitive.
---

In addition, Camellia satisfies all current requirements of TLS-BCP draft,
and is already implemented in major software, such as OpenSSL, GnuTLS,
NSS, and Linux.
Therefore, once again, I wish the following cipher suites with Camellia
specified by RFC6367 [4] are also expressed in TLS-BCP.

---
TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256
TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384
---

[1] NESSIE Project,
http://www.cosic.esat.kuleuven.be/nessie/

[2] ISO/IEC18033-3,
http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=37972

[3] Algorithms, Key Sizes and Parameters Report
2013 recommendations,
http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report/at_download/fullReport

[4] RFC 6367 Addition of the Camellia Cipher Suites to Transport Layer
Security (TLS), http://tools.ietf.org/html/rfc6367

Best,
Kohei KASAMATSU

(2014/08/28 19:27), Stephen Farrell wrote:
> 
> Hiya,
> 
> Having had this discussion a few times over the last
> couple of years my take on it is:
> 
> - there is some but not huge interest a backup cipher
>    for AES and the interest-level varies by protocol
>    as do the set of possible backups
> 
> - we are very unlikely to get an easy consensus on which
>    to pick, or how to pick (has been tried in both SAAG
>    and CFRG without success), as a generic backup
> 
> - picking a cipher is not a UTA thing, and not the same
>    as picking a TLS ciphersuite, which can be a UTA thing
> 
> - while Camellia ciphersuites exist, chacha20 ciphersuites
>    seem like they are also getting traction as an
>    alternative to AES when one doesn't have AES h/w, but
>    its too soon to tell maybe - if that happened, then there
>    is also a reason to support chacha20 in addition to it
>    being a backup to AES. And 2 reasons are way better
>    than one here.
> 
> I conclude that UTA should not be in the business of
> trying to decide which cipher might be a good backup
> for AES.
> 
> And since TLS ciphersuites are in flux, with RC4 on
> the way out and (apparently) chacha20 on the rise,
> this isn't the right time for UTA to pick another
> ciphersuite as a backup in case of problems with AES.
> 
> Cheers,
> S.
> 
> 
> On 28/08/14 09:37, Kohei Kasamatsu wrote:
>> Hi Yaron and Leif,
>>
>>
>> I also need a consensus about adding standby ciphers into TLS-BCP.
>> And I understood that UTA WG focuses on getting a first version of the
>> BCP out as soon as possible.
>>
>> In first, I want to point out it seems that very little interest in the
>> idea of standby cipher that you pointed out is not fact.
>> I heard from David that there are some interests in idea of standby ciphers.
>>
>> My concern is that when vulnerability related to the primitive is found
>> it takes a lot of time to migrate from insecure primitive to secure one.
>> In fact, it is seemed to me that it takes a lot of time to migrate to
>> TLS1.2. (My proposal that TLS-BCP recommends standby ciphers is one of
>> the solutions for a delay of migration.)
>>
>> What do you think about my concern?
>>
>> For example, shall we consider the procedure for review of algorithms in
>> TLS-BCP and update of TLS-BCP in order to deal with the following events?
>>
>> 1. Operations of new algorithms in TLS implementations are so increasing
>> that we cannot ignore it.
>>
>> 2. Vulnerability of TLS is found.
>>
>> Best,
>> Kohei KASAMATSU
>>
>> (2014/08/11 18:33), Leif Johansson wrote:
>>> On 2014-08-11 10:44, Yaron Sheffer wrote:
>>>> Hi Kohei,
>>>>
>>>> Personally I support the idea of alternative (or "standby") ciphers, see
>>>> http://tools.ietf.org/html/draft-mcgrew-standby-cipher-00. However there
>>>> was very little interest in this idea when we brought it up at CFRG.
>>>>
>>>> IMHO for inclusion in the BCP there should be wide consensus about both
>>>> the need for standby ciphers (and there is none, as far as I can tell)
>>>> as well as the individual algorithms.
>>>>
>>>
>>> I think that is a fair assessment. Our focus now should be on getting a
>>> first version of the BCP out as soon as possible.
>>>
>>> 	Cheers Leif
>>>
>>> _______________________________________________
>>> Uta mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/uta
>>>
>>
>> _______________________________________________
>> Uta mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/uta
>>
>>
> 

-- 
Kohei KASAMATSU

NTT Software Corporation
TEL: +81 45-212-7252 FAX: +81 45 212 9800
E-mail: [email-masked]

---

From: Ralph Holz <[email-masked]>
Date: Thu, 11 Sep 2014 12:59:03 +0200

Hi Kohei,

I think Stephen has rather expressed he would not want UTA to pick a
backup cipher suite for TLS.

The purpose of the BCP is to give advice which cipher suite to
configure. Your proposal would have us double the number of suites
without a clear recommendation which one to use, which I'd like to
avoid. Add to that the people who'd rather see a different one picked
and we'd have more delay in publishing the RFC.

The fact that implementations of Camellia exist does not mean they are
error-free. The cipher is in little use, too, so I doubt the
implementations have seen a lot of scrutiny.

In summary, I would rather not have Camellia added. A backup cipher
suite should see more vetting than we can do in this RFC and at this time.

Ralph

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18010
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 11 Sep 2014 12:04:20 +0100

Hiya,

Your desire to add 4 Camellia ciphersuites is not at all
unreasonable, but I still myself think it would be a bad
plan right now. Better I (still:-) think to get this BCP
out the door now with just AES ciphersuites and look at
it again later when the chacha20/rc4 situation settles
down.

I think this BCP ought where possible match what's in
widespread use and is best practice. Right now, AES and
RC4 ciphersuites are used in most places as far as I know
but we want to see RC4 go away.

In future it could be AES and Camellia or AES and chacha20
or something else, but I don't think it'd be correct now
to say that AES+Camellia ciphersuites are the BCP since
Camellia is not as far as I know in such widespread use.

Cheers,
S.

---

From: Leif Johansson <[email-masked]>
Date: Thu, 11 Sep 2014 13:42:29 +0200

Folks,

As interesting as this is, it is out of scope for UTA and is probably
better suited as a discussion on the SAAG list.

	Cheers leif

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 11 Sep 2014 14:18:47 +0200

> implementations have seen a lot of scrutiny.

I doubt that. Camellia was even preferred to AES in browsers like chrome
and firefox for quite long time (that is no longer the case though).
https://bugzilla.mozilla.org/show_bug.cgi?id=430875
http://crypto.stackexchange.com/questions/6530/why-is-camellia-suddenly-so-widely-used

So there is no technical reason for not having camellia in a BCP.

regards,
Nikos

---

From: Ralph Holz <[email-masked]>
Date: Thu, 11 Sep 2014 15:00:33 +0200

Hi,

> So there is no technical reason for not having camellia in a BCP.

Fair enough, but what about PolarSSL or GnuTLS? Not saying the devs
didn't do their job; just that we might rush something here.

Anyway, Leif has also indicated it is out of scope...

Ralph

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 11 Sep 2014 16:20:59 +0200

Hi,

I originally intended to go with a lengthy text on my experience with
CAMELLIA over the last couple of years, but I agree that this is
completely off topic. I've had extensive discussions about the issue
with implementers, but what it should boil down to in UTA is that this
is not a decision that we should make but rather hand over to CFRG and SAAG.

Thanks,
Aaron

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 11 Sep 2014 18:16:00 +0200

> didn't do their job; just that we might rush something here.

What about them? Do you have any reasons to believe that the
implementation there is flawed? As I'm the one who develops gnutls I
have no such reasons to believe so.

regards,
Nikos

---

From: Leif Johansson <[email-masked]>
Date: Mon, 15 Sep 2014 10:55:29 +0200

Folks,

Could we please move the Camellia appreciation society over to SAAG and
focus the energy to review of the many *other* aspects of the BCP draft
that are in fact up for discussion?

	The chairs