* Tapio Sokura <[email protected]> [141222 02:32]: > Hi, > > Thanks for the replies guys, I understand your viewpoint. I'm just > worried that in the future the knobs for corner cases like deliberately > turning on NULL won't be in the software/specs at all. If you are in a > scenario where you can't encrypt and NULL ciphers can't be used because > the software/specs don't support it, then you can't use TLS at all, not > even for providing integrity and authentication. > > I did notice the wordings that limit the applicability of the BCP in > these kinds of cases. Anyway there's a difference between intentionally > running no crypto and running a so-so crypto like RC4 with TLS; if you > intentionally run crypto to provide confidentiality you might as well > run the best you can.
I don't understand the argument here. These are very specific corner cases. In these you'd probably use older versions of the protocol that support NULL ciphers on both ends. For example, in the HPC community it's quite common for large file transfers to use SSH with a NULL cipher (since data confidentiality is mostly not an issue - depending on the project and so on). PSC maintains a patched version of SSH/SCP for exactly that purpose: http://www.psc.edu/index.php/hpn-ssh That being said - a couple of months ago I benchmarked their MT-CTR patches against upstream OpenSSH, their performance was worse than upstreams without these specific patches. Which reminds me, I should write them a mail about that. Aaron
signature.asc
Description: Digital signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
