Hi Hanno, No, the tests have not been published. I can look at trying to make this data publicly available but I cannot guarantee that.
Tests were generally done with AES and SHA hashing. One reason for this is that many in this industry have incorporated some hardware-based crypto acceleration into products, and it's been the case that this hardware has not included ChaCha20. Although future products can include ChaCha20, in some industries (like Industrial Automation) hardware support can easily span 20 years, so the install base of products without ChaCha20 is non-trivial. I do take your point around implementation pitfalls, and I realize that for the use cases that most on this list have in mind (e.g. Internet-based web communications) a cipher like this does not seem useful at all. However there are a lot of IoT devices, and especially industrial devices, that would really benefit from being able to use TLS 1.3 to secure their communications. These devices are growing rapidly in connectivity so communications security is becoming more and more important/pressing. I don't represent a library vendor but I'd think this being optional would lend itself well to being compiled out of a library unless needed. Thanks, --Jack -----Original Message----- From: Hanno Böck <ha...@hboeck.de> Sent: Wednesday, February 27, 2019 4:31 AM To: Jack Visoky <jmvis...@ra.rockwell.com> Cc: tls@ietf.org Subject: Re: EXTERNAL: Re: [TLS] Authentication Only Ciphersuites RFC 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
