> Based on long experience in the IETF, this seems like the opposite of > a BCP. Protocols that have had multiple mandatory-to-implement > algorithms "in case there was a crypto failure" have led to > interoperability failures and confusion for users.
You mean that if protocols have multiple mandatory-to-implement (MTI) algorithms some of these MTI algorithms are not implemented and it causes interoperability failures? > Clearly, TLS needs to have crypto agility in case of crypto failures, > but the current BCP does not prevent that. Why cannot "current" BCP prevent that? Best, Kohei KASAMATSU (2014/07/30 22:45), Paul Hoffman wrote: > On Jul 24, 2014, at 3:36 PM, Kohei Kasamatsu <[email protected]> wrote: > >> I strongly believe that BCP needs to include alternative algorithms >> - with different design policy from algorithm which your I-D recommends >> - which are widely implemented >> - which are internationally standardized >> >> Because when protocols depend on single primitive and vulnerability >> related to the primitive is found it takes a lot of time to migrate from >> insecure primitive to secure one. > > Based on long experience in the IETF, this seems like the opposite of a BCP. Protocols that have had multiple mandatory-to-implement algorithms "in case there was a crypto failure" have led to interoperability failures and confusion for users. Clearly, TLS needs to have crypto agility in case of crypto failures, but the current BCP does not prevent that. But "alternative algorithms" has been shown to have negative effects. > > --Paul Hoffman > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta > _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
