Against certain proposed TLS client-side options

Richard Laager rlaager at wiktel.com
Sun Feb 3 00:08:13 UTC 2019


On 2/2/19 5:16 AM, Eric S. Raymond via devel wrote:
> NEVER CONFIGURE WHAT YOU CAN DISCOVER
> 
> These are from nts.adoc:
> 
>      *tls1.2* Allow TLS1.2 connection.
> 
>      *tls1.3* Allow TLS1.3 connection.
> 
> We don't need these because in this 'graph
> 
>      Implementations MUST NOT negotiate TLS versions earlier than 1.2,
>      SHOULD negotiate TLS 1.3 [RFC8446] or later when possible, and MAY
>      refuse to negotiate any TLS version which has been superseded by a
>      later supported version.
> 
> the last normative is a MAY, not a MUST.  Thus, you never need to do
> anything but allow some connection at 1.2 or up even once 1.2 is
> superseded. Correct[racticr is to use the highest version you have.
> 
> We also don't need these.
> 
>      *tls1.2ciphers [list]*  List of TLS 1.2 ciphers to negotiate, in prefered
>      order.  The list is one or more cipher names, separated by colons.
> 
>      *tls1.3ciphers [list]*  List of TLS 1.3 ciphers to negotiate, in prefered
>      order.  TLS 1.2 and 1.3 ciphers are different and must be specified
>      separately as OpenSSL needs them separately.
> 
>      *ntpciphers [list]* List of ciphers to negotiate, in prefered order for
>      the NTPD connection.  The server must support AEAD_AES_SIV_CMAC_256.
> 
> The correct, conformant policy is to negitiate your best possible TLS
> version, then ask your TLS implementation what its list of ciphers
> for that level is, then ship that.

Your TLS library will negotiate the best TLS version. That's literally
the entire point of TLS negotiation.

HOWEVER, various (non-binding and) binding security standards require
that you disable old TLS versions.

At one time, this unquestionably made security sense, as it protected
against downgrade attacks. Imagine:

Alice --> Bob

Alice announces, "I support SSLv3, TLS 1.0, 1.1, 1.2, and 1.3." Bob
supports TLS 1.0, 1.1, and 1.2. Bob will use 1.2. That's how negotiation
works.

Now add Eve as a MITM (WITM?):

Alice --> Eve --> Bob

Alice announces, "I support SSLv3, TLS 1.0, 1.1, 1.2, and 1.3." Eve
(maybe having probed Bob) changes that to "I support TLS 1.0.". Bob will
use TLS 1.0. This is a downgrade attack.

If your security standards require you to set a minimum TLS version (as
either client or server), then you fail hard (good!) rather than having
your security broken (bad!).

Now, is this still necessary after RFC 7507? That's potentially
debatable. If everyone implemented RFC 7507, maybe not. I'm not enough
of a crypto and TLS expert to say for sure. But given that probably not
everyone does implement it, and more importantly, that it is only a
solution for clients not servers, I think you're still going to see
security standards requiring minimum TLS versions.

And most importantly, it does not matter if you or I think the binding
security standard is incorrect. If a binding standard, backed by
auditing and financial penalties, says that I need to configure a
minimum TLS version, I need to do that. The only time I'd consider
violating a binding standard is if they recommendation makes my security
_worse_, or completely breaks critical communications where I have no
other choice, not if it merely introduces an unnecessary config change.

-- 
Richard


More information about the devel mailing list