[openssl-project] When to enable TLS 1.3 (was: Google's SNI hurdle)

[Viktor Dukhovni]

> On Apr 19, 2018, at 1:48 PM, Matt Caswell <matt at openssl.org> wrote:
> 
>> I might suggest conditioning it on the compile-time version of OpenSSL
>> headers. This is a common transition strategy for systems working
>> through ABI constraints. (In some systems, this is implemented as some
>> target SDK version.)
> 
> This is exactly what Richard proposed in this PR:
> 
> https://github.com/openssl/openssl/pull/5945

So we should get back to what to do about the larger question.

I am skeptical that just the compile-time header version is a
sufficiently good indicator of which applications are prepared
for TLS 1.3.  For most applications integration into a new
release involves recompiling the existing code and running some
tests.

If the tests don't cover interoperability with a sufficiently
diverse set of remote peers, the application will be no more
prepared for TLS 1.3 after compilation against OpenSSL 1.1.1
than it would have been had it been compiled against 1.1.0.

So ideally we (collectively, the OpenSSL, Google, other
TLS toolkits and service providers) will work to reduce
friction so that more applications can use TLS 1.3 without
running into any issues.

But not all the friction can be eliminated, and likely not
all providers can be persuaded to be more accommodating.
Which leaves us with some difficult judgement calls:

  * Restrict TLS 1.3 support to just applications compiled
    against 1.1.1?  A weak signal, but likely correlates at
    least somewhat with the application being ready.

  * Determine whether the application is likely to be compatible
    at runtime by looking at the provided configuration.  Is SNI
    enabled?  Is the certificate chain weird enough to break with
    TLS 1.3.  Has the application turned off critical algorithms?

  * Do nothing, let the applications adapt or stick with older
    libraries?

  * Something else?

We don't have much time before release, what do we do?

-- 
	Viktor.