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
On 09/11/2014 12:42 PM, 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
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/uta
>>>>
>>>
>>> _______________________________________________
>>> Uta mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/uta
>>>
>>>
>>
>
>
--
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
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
