[gnutls-devel] GnuTLS | Compiled-in, yet unsupported by default, TLS versions (!1157)
Development of GNU's TLS library
gnutls-devel at lists.gnutls.org
Tue Jan 7 12:55:24 CET 2020
Nikos Mavrogiannopoulos commented:
I'm wondering whether this will make settings more complicated. So with this the intention is to introduce a "soft" disable, which it can later be re-enabled using configuration. The approach we took before was that whatever is disabled explicitly in release it cannot be re-enabled. The reason is to avoid someone overriding the software distributor's expectations in terms of minimum security. That is, the system ships with a minimum bar, and applications or admins can go higher with more strict config. It is documented as:
```
It intentionally does not allow switching algorithms or protocols
which were disabled or marked as insecure during compile time to the secure
set. This is to prevent the feature from being used to attack the system.
```
What you are suggesting is to not have a minimum bar but instead bar which can go either ways on run-time. This eliminates the intended use, but more than that I think that makes things quite more complicated. I understand from the ML communication is that you prefer not to use configuration files in the default case (e.g., to disable tls1.1 and tls1.0, but could you share more background why is that? It could be that the model we selected is flawed, and there can be a better way to do it, but I would like to understand why introduce additional complexity when we can handle the issue with a configuration file.
--
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1157#note_268070486
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20200107/81c582ef/attachment.html>
More information about the Gnutls-devel
mailing list