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 protected]
>>> https://www.ietf.org/mailman/listinfo/uta
>>>
>>
>> _______________________________________________
>> Uta mailing list
>> [email protected]
>> 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 protected]
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
