Hi,
> I appreciate your concerns here, but I can only agree with it to some > degree, and inclusion in this version of the BCP is probably not a good > idea. Maybe adding a subsection on alternative algorithms in case of a > crypto break-through (e.g. on AES) is an option, but even here I am > skeptical. > > Adding equivalent alternatives in the BCP without that understanding > would be agains the intention of the BCP, IMO. I understood that you disagree with inclusion of alternative algorithms in the BCP because adding equivalent alternatives in the BCP be against the intention of the BCP. I believe that intension of your draft is to encourage to deploy secure algorithms that are widely implemented because of recent attacks [I-D.sheffer-uta-tls-attacks] from the following part of introduction and recommendations of TLS1.2 (*1) and Brainpool curves (*2) in your draft. -- A companion document [I-D.sheffer-uta-tls-attacks] provides detailed information about these attacks. Because of these attacks, those who implement and deploy TLS and DTLS need updated guidance on how TLS can be used securely. Note that this document provides guidance for deployed services, as well as software implementations. In fact, this document calls for the deployment of algorithms that are widely implemented but not yet widely deployed. -- *1 TLS1.2 is supported by 37% of sites as Ivan's data (http://www.ietf.org/mail-archive/web/uta/current/msg00439.html) *2 Brainpool curves are implemented in OpenSSL 1.0.2 and are not implemented in OpenSSL 1.0.1 and is not supported by IE, Google Chrome, and Firefox. Furthemore, TLS-BCP shows problems of dependence on single primitive and alternative algorithms are countermeasure against it. I believe that the countermeasure is suitable for your draft because it enables TLS-BCP draft to deals with vulnerability taking alternative algorithm into consideration. > Is it implemented in IE? Is it supported by Chrome? If the answer to one > of these questions is No, it should not be included in the BCP. Same > goes for Seed. I have no data here - anyone? As Aaron says, Camellia is included to be supported by Firefox and SEED is not included to be supported by Firefox, IE, and Chrome. However, it is enough to recommend the deployment in your draft based on implementations of Brainpool curves. >> singnature: >> * ECDSA >> - is based on ECDLP (the security of RSA is based on >> integer factring.) >> - is implemented in OpenSSL 1.0.2, GnuTLS 3.3.5, NSS 3.15.1 and so on. > > Same questions. As Aaron says, ECDSA is widely implemented as of today. Best, Kohei KASAMATSU (2014/07/30 19:35), Ralph Holz wrote: > Hi, > >> I am referring to symmetric key encryption, signature, mode of >> operations for constructing AEAD, and MAC. >> (as you pointed out, we already have alternatives for public key encryption) >> >> Do you agree with the necessity of alternative algorithms? > > I appreciate your concerns here, but I can only agree with it to some > degree, and inclusion in this version of the BCP is probably not a good > idea. Maybe adding a subsection on alternative algorithms in case of a > crypto break-through (e.g. on AES) is an option, but even here I am > skeptical. > > Adding equivalent alternatives in the BCP without that understanding > would be agains the intention of the BCP, IMO. > > As for the algorithms, I have some doubts: > >> [Rationale] >> symmetric key encryption: >> * Camellia >> - have different design policy (Feistel Structure) from AES >> (SPN Structure) >> - is implemented in OpenSSL 1.0.2, GnuTLS 3.3.5, NSS 3.15.1 and so on. > > Is it implemented in IE? Is it supported by Chrome? If the answer to one > of these questions is No, it should not be included in the BCP. Same > goes for Seed. I have no data here - anyone? > >> singnature: >> * ECDSA >> - is based on ECDLP (the security of RSA is based on >> integer factring.) >> - is implemented in OpenSSL 1.0.2, GnuTLS 3.3.5, NSS 3.15.1 and so on. > > Same questions. > >> mode of operations: - > > [CCM] > > I see no reason to include this here - support seems to be lacking. > >> MAC: - >> * There is only HMAC as alternative algorithm and >> And there is HMAC-SHA-3 as candidate of alternative hash function. > > Same reason here. > > Ralph > _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
