[openssl-project] When to enable TLS 1.3 (was: Google's SNI hurdle)
openssl-users at dukhovni.org
Thu Apr 19 23:16:04 UTC 2018
> 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:
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
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
* Something else?
We don't have much time before release, what do we do?
More information about the openssl-project