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