Hubert Kario <hka...@redhat.com> writes: >Because there are software stacks that allow configuration of arbitrary >parameters for FFDH (see GnuTLS, OpenSSL), and there are software stacks that >generate one public key share and reuse it for a long time, or allow >configuration of this kind of behaviour (see old OpenSSL, NSS for ECDHE).
If we had to throw out every security mechanism that it's possible to configure badly then there wouldn't be any crypto left. For example every SSH server in existence can be configured to use username = root, password = password, but that doesn't mean we need to mandate ZKP authentication as the only allowed way to log into an SSH server. It's also quite likely you can configure a lot of TLS servers to use RC4/40 (at least with OpenSSL-based ones it's 'enable-weak-ssl-ciphers') but that doesn't mean we need to deprecate all use of symmetric crypto. If people want to go out of their way to make their server insecure then there's not much we can do to stop them. This is a bit of a philosophical question here, and probably not worth debating, but is it really necessary to put "Do not hold the wrong end of a chainsaw" - that's actually used on chainsaws - in a technical RFC? That's something for the software vendor to take care of if they're going to allow settings for users to shoot themselves in the foot. Even for the proposed BCP it seems a bit redundant, why single out this particular, probably almost nonexistent, misconfiguration when there are hundreds or even thousands of others that are more likely to occur? Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
