Against certain proposed TLS client-side options

[Richard Laager]

On 2/2/19 7:11 PM, Eric S. Raymond wrote:
> Richard Laager via devel <devel at ntpsec.org>:
>> On 2/2/19 4:52 PM, Eric S. Raymond via devel wrote:
>>> Gary E. Miller via devel <devel at ntpsec.org>:
>>>> On Sat,  2 Feb 2019 06:16:45 -0500 (EST)
>>>> "Eric S. Raymond via devel" <devel at ntpsec.org> wrote:
>>
>>>> The list of allowed versions, and even names, will change.  Sometimes
>>>> overnight as we have seen many times.
>>>
>>> Of course it will.  That is irrelevant to where options to suppress
>>> capabilities are needed, because the right behavior is always "allow
>>> everything above the last version implicated in a crypto emergency"...
>>
>> It's not that simple. For a real world example...
> 
> forcetls is in my to-do list.  I intended it to address Gary's concern
> about testing, but it would handle the kind of emergency you're describing.
> Or am I wrong about that?

In the example I gave, the cipher list is what was used to address the
emergency. And again, you SHOULD (almost a MUST) treat that as an opaque
string and just give it to OpenSSL. Likewise for ciphersuites, which is
really the same thing but for TLS 1.3+.

Having a TLS minimum option (or an option providing a list of TLS
versions) addressed the other piece when TLS 1.2 needed to be required.

Again, these aren't required for a first ship, but you really do need
these options (ciphers as long as you support TLS 1.2, ciphersuites,
mintls || tlsversions) at some point before this is declared "finished".

I'm not aware of any auditing requirement that requires a maximum TLS
version, but the Firefox link I posted seemed to hint that maybe the DOD
STIG requirements did require setting a maximum TLS version. Most people
aren't going to do that, but maybe the DoD is being ultra conservative,
by not allowing new TLS versions until they have been audited.

If you provide EITHER a tlsversions OR both a tlsmin and tlsmax, you
have provided the equivalent of "forcetls" for testing. I would suggest
that if you want a "forcetls", you provide either tlsversions (as Gary
wants) or both tlsmin and tlsmax. That way, if someone (e.g. the DoD)
does need to specify a maximum TLS version, you've covered them too.

In other words, here are the use cases:

# Requiring a minimum TLS 1.3
# (common in the future based on past experience)
tlsmin 1.3
OR
tlsversions "1.3"

# Requiring a bounded set of audited TLS versions
# (the DOD STIG scenario, unverified as to actual requirement)
tlsmin 1.2 tlsmax 1.3
OR
tlsversions "1.3"
# Notably, forcetls is NOT acceptable here, as even if it is per
# association, which I think we are assuming, it breaks negotiation.
# Clients and servers would have to upgrade in lock-step, which is
# unreasonable to expect.

# Testing TLS 1.2
# (probably developers only)
tlsmin 1.2 tlsmax 1.2
OR
tlsversions "1.2"
OR
forcetls 1.2

# Testing TLS 1.3
# (probably developers only)
tlsmin 1.3 tlsmax 1.3
OR
tlsversions "1.3"
OR
forcetls 1.3

So given that tlsversions OR (tlsmin AND tlsmax) cover all the scenarios
of forcetls, but the reverse is not true, I think you should pick one of
those options instead of forcetls.

-- 
Richard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190202/1e5bbd2e/attachment-0001.bin>