Hi, On Tue, 26 Feb 2019 21:26:45 +0000 Jack Visoky <jmvis...@ra.rockwell.com> wrote:
> We have done tests on this and it there is a difference. Have these tests in any way been published? Because otherwise it's a very weak argument. There are some obvious questions, e.g.: * What algorithm implementation was tested, was it optimized for the architecture in question and was it considered whether the optimization could be improved or maybe even whether already a more optimized implementation exists? * Have you tried both AES and chacha20? And in both cases the most optimized implementation for the target plattform? * If the bottleneck is the cipher have you considered whether a different cipher that provides reasonable security, but can be implemented better on lightweight hardware, would be an alternative? (Not keen having that option, I believe fewer options are better.) > This probably goes without > saying but of course the best line of defense is to properly design, > build, and configure the implementation. I'm inclined to say that this is an outdated view of how to best do security in protocols. We had plenty of situations in the past where the TLS spec was a minefield of possible implementation mistakes that led to long descriptions on how to properly design things to avoid these mistakes. History shows it didn't work. (Let me just throw in "Padding Oracles" or "Bleichenbacher attacks" as very obvious examples.) My takeaway and I believe that of many people is that the protocol should avoid implementation pitfalls whereever possible. And I believe an authentication-only ciphersuite is a dangerous implementation pitfall. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
