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

[Kurt Roeckx]

On Thu, Apr 19, 2018 at 07:16:04PM -0400, Viktor Dukhovni wrote:
> 
>   * Something else?

We could call for testing what really happens on -users? I could
also send one to debian-devel-announce, we already have pre4 in
experimental.

Maybe we can convert the blog post into a wiki, update it to the
current status, and point people to that.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

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

[Kurt Roeckx]

On Thu, Apr 19, 2018 at 07:16:04PM -0400, Viktor Dukhovni wrote:
> 
> 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.

Applications get rebuild for all sort of reasons, I don't actually
see this as a good signal at all.

>   * 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?

I'm for keeping this as they are now. After the release some
things might break. Applications will adapt.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[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  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.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project