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

[Stephen Farrell <[e-mail]>]

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.

On 11/09/14 11:42, Kohei Kasamatsu wrote:
> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/uta
>>>>
>>>
>>> _______________________________________________
>>> Uta mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/uta
>>>
>>>
>>
> 
>