Re: [openssl-project] When to enable TLS 1.3

2018-04-29 Thread Kurt Roeckx
On Sat, Apr 28, 2018 at 04:32:42PM -0400, Viktor Dukhovni wrote:
> 
> 
> > On Apr 28, 2018, at 2:41 PM, Kurt Roeckx  wrote:
> > 
> > So should I send that mail?
> 
> I made some editorial changes to the Wiki section on SNI.
> No strong views on sending the mail...

So I've sent it.


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

2018-04-28 Thread Viktor Dukhovni


> On Apr 28, 2018, at 2:41 PM, Kurt Roeckx  wrote:
> 
> So should I send that mail?

I made some editorial changes to the Wiki section on SNI.
No strong views on sending the mail...

-- 
Viktor.

___
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

2018-04-28 Thread Kurt Roeckx
On Fri, Apr 27, 2018 at 11:29:28PM +0200, Kurt Roeckx wrote:
> On Sat, Apr 21, 2018 at 03:47:03PM -0400, Viktor Dukhovni wrote:
> > 
> > 
> > > On Apr 21, 2018, at 3:45 PM, Kurt Roeckx  wrote:
> > > 
> > >>> The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
> > >>> 1.3 brings a lot of changes that might cause incompatibility. For
> > >>> an overview see https://wiki.openssl.org/index.php/TLS1.3
> > >> 
> > >> Should the Wiki mention the observed SNI issue?
> > > 
> > > It's really a change in other libraries, but since it can cause
> > > issues, feel free to add it.
> > 
> > OK, if find the cycles...
> 
> I've added a section on that page about it.

So should I send that mail?


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

2018-04-27 Thread Kurt Roeckx
On Sat, Apr 21, 2018 at 03:47:03PM -0400, Viktor Dukhovni wrote:
> 
> 
> > On Apr 21, 2018, at 3:45 PM, Kurt Roeckx  wrote:
> > 
> >>> The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
> >>> 1.3 brings a lot of changes that might cause incompatibility. For
> >>> an overview see https://wiki.openssl.org/index.php/TLS1.3
> >> 
> >> Should the Wiki mention the observed SNI issue?
> > 
> > It's really a change in other libraries, but since it can cause
> > issues, feel free to add it.
> 
> OK, if find the cycles...

I've added a section on that page about it.


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

2018-04-23 Thread Viktor Dukhovni


> On Apr 22, 2018, at 12:16 PM, Richard Levitte  wrote:
> 
> openssl-users> > We are considering if we should enable TLS 1.3 by default or 
> not,
> openssl-users> > or when it should be enabled. For that, we would like to 
> know how
> openssl-users> > applications behave with the current version.
> openssl-users> 
> openssl-users> It is perhaps unclear in the last sentence what "the current 
> version"
> openssl-users> means.
> 
> I took that to mean "the 1.1.0 series"

I meant unclear to potential readers, rather than project maintainers. :-)

-- 
Viktor.

___
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

2018-04-23 Thread Richard Levitte
In message <431270c5-3da3-4a9d-9292-12adc46cc...@dukhovni.org> on Sat, 21 Apr 
2018 14:45:34 -0400, Viktor Dukhovni  said:

openssl-users> > We are considering if we should enable TLS 1.3 by default or 
not,
openssl-users> > or when it should be enabled. For that, we would like to know 
how
openssl-users> > applications behave with the current version.
openssl-users> 
openssl-users> It is perhaps unclear in the last sentence what "the current 
version"
openssl-users> means.

I took that to mean "the 1.1.0 series"

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
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

2018-04-21 Thread Viktor Dukhovni


> On Apr 21, 2018, at 3:45 PM, Kurt Roeckx  wrote:
> 
>>> The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
>>> 1.3 brings a lot of changes that might cause incompatibility. For
>>> an overview see https://wiki.openssl.org/index.php/TLS1.3
>> 
>> Should the Wiki mention the observed SNI issue?
> 
> It's really a change in other libraries, but since it can cause
> issues, feel free to add it.

OK, if find the cycles...

> 
>>> We are considering if we should enable TLS 1.3 by default or not,
>>> or when it should be enabled. For that, we would like to know how
>>> applications behave with the current version.
>> 
>> It is perhaps unclear in the last sentence what "the current version"
>> means.
> 
> So: with the latest beta release?

Yes, that's better.

-- 
Viktor.

___
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

2018-04-21 Thread Kurt Roeckx
On Sat, Apr 21, 2018 at 02:45:34PM -0400, Viktor Dukhovni wrote:
> 
> 
> > On Apr 21, 2018, at 2:42 PM, Kurt Roeckx  wrote:
> > 
> > Here is some attempt:
> > 
> > The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
> > 1.3 brings a lot of changes that might cause incompatibility. For
> > an overview see https://wiki.openssl.org/index.php/TLS1.3
> 
> Should the Wiki mention the observed SNI issue?

It's really a change in other libraries, but since it can cause
issues, feel free to add it.

> > We are considering if we should enable TLS 1.3 by default or not,
> > or when it should be enabled. For that, we would like to know how
> > applications behave with the current version.
> 
> It is perhaps unclear in the last sentence what "the current version"
> means.

So: with the latest beta release?


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

2018-04-21 Thread Viktor Dukhovni


> On Apr 21, 2018, at 2:42 PM, Kurt Roeckx  wrote:
> 
> Here is some attempt:
> 
> The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
> 1.3 brings a lot of changes that might cause incompatibility. For
> an overview see https://wiki.openssl.org/index.php/TLS1.3

Should the Wiki mention the observed SNI issue?

> We are considering if we should enable TLS 1.3 by default or not,
> or when it should be enabled. For that, we would like to know how
> applications behave with the current version.

It is perhaps unclear in the last sentence what "the current version"
means.

> We would really like to see a diveerse set of applictions being
> tested. Please report any results you have to us.

s/diveerse/diverse/

-- 
Viktor.

___
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

2018-04-21 Thread Kurt Roeckx
On Sat, Apr 21, 2018 at 05:19:31PM +0200, Kurt Roeckx wrote:
> On Fri, Apr 20, 2018 at 10:16:55AM +0100, Matt Caswell wrote:
> > On 20/04/18 09:11, Kurt Roeckx wrote:
> > > On Fri, Apr 20, 2018 at 09:11:39AM +0200, Kurt Roeckx wrote:
> > >>
> > >> Maybe we can convert the blog post into a wiki, update it to the
> > >> current status, and point people to that.
> > > 
> > > I've converted to blog to the wiki:
> > > https://wiki.openssl.org/index.php/TLS1.3
> > > 
> > > I've made some minor changes, it could use better formatting, and
> > > at least the section about ciphersuites is outdated.
> > 
> > I have updated the ciphersuites section and fixed the man page links, as
> > well as a few other content tweaks here and there.
> 
> Thanks.
> 
> So should we send out some call for testing? Does someone want to
> write a draft message?

Here is some attempt:

The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
1.3 brings a lot of changes that might cause incompatibility. For
an overview see https://wiki.openssl.org/index.php/TLS1.3

We are considering if we should enable TLS 1.3 by default or not,
or when it should be enabled. For that, we would like to know how
applications behave with the current version.

When testing this, it's important that both sides of the
connection support the same TLS 1.3 draft version. OpenSSL
currently implements draft 26. We would like to see tests
for OpenSSL acting as client and server.

https://github.com/tlswg/tls13-spec/wiki/Implementations lists
other TLS 1.3 implementations and the draft they currently
support. Note that the versions listed there might not be for the
latest release. It also lists some https test servers.

We would really like to see a diveerse set of applictions being
tested. Please report any results you have to us.


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

2018-04-21 Thread Kurt Roeckx
On Fri, Apr 20, 2018 at 10:16:55AM +0100, Matt Caswell wrote:
> On 20/04/18 09:11, Kurt Roeckx wrote:
> > On Fri, Apr 20, 2018 at 09:11:39AM +0200, Kurt Roeckx wrote:
> >>
> >> Maybe we can convert the blog post into a wiki, update it to the
> >> current status, and point people to that.
> > 
> > I've converted to blog to the wiki:
> > https://wiki.openssl.org/index.php/TLS1.3
> > 
> > I've made some minor changes, it could use better formatting, and
> > at least the section about ciphersuites is outdated.
> 
> I have updated the ciphersuites section and fixed the man page links, as
> well as a few other content tweaks here and there.

Thanks.

So should we send out some call for testing? Does someone want to
write a draft message?


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

2018-04-20 Thread Matt Caswell


On 20/04/18 09:11, Kurt Roeckx wrote:
> On Fri, Apr 20, 2018 at 09:11:39AM +0200, Kurt Roeckx wrote:
>>
>> Maybe we can convert the blog post into a wiki, update it to the
>> current status, and point people to that.
> 
> I've converted to blog to the wiki:
> https://wiki.openssl.org/index.php/TLS1.3
> 
> I've made some minor changes, it could use better formatting, and
> at least the section about ciphersuites is outdated.

I have updated the ciphersuites section and fixed the man page links, as
well as a few other content tweaks here and there.

Matt

___
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)

2018-04-20 Thread Kurt Roeckx
On Fri, Apr 20, 2018 at 09:11:39AM +0200, Kurt Roeckx wrote:
> 
> Maybe we can convert the blog post into a wiki, update it to the
> current status, and point people to that.

I've converted to blog to the wiki:
https://wiki.openssl.org/index.php/TLS1.3

I've made some minor changes, it could use better formatting, and
at least the section about ciphersuites is outdated.


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)

2018-04-20 Thread 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

2018-04-19 Thread Richard Levitte
In message  on Thu, 19 Apr 
2018 19:16:04 -0400, Viktor Dukhovni  said:

openssl-users> But not all the friction can be eliminated, and likely not
openssl-users> all providers can be persuaded to be more accommodating.
openssl-users> Which leaves us with some difficult judgement calls:
openssl-users> 
openssl-users>   * Restrict TLS 1.3 support to just applications compiled
openssl-users> against 1.1.1?  A weak signal, but likely correlates at
openssl-users> least somewhat with the application being ready.
openssl-users> 
openssl-users>   * Determine whether the application is likely to be compatible
openssl-users> at runtime by looking at the provided configuration.  Is SNI
openssl-users> enabled?  Is the certificate chain weird enough to break with
openssl-users> TLS 1.3.  Has the application turned off critical algorithms?

Of those two, the second provides for a smoother transition to using
TLSv1.3, all it might take is changing a configuration, getting a
newer certificate with a more compatible chain, changing an engine
module.  Some of those may take some time (even purchasing a new cert,
what do I know?), but still.  If at all possible, the second choice
seems like the better one.

The only reason I can see for the first option is if there are things
that cannot be detected in run-time that would cause the use of older
protocols rather than TLSv1.3.  I suspect a too early call of
SSL_version might be one that's hard to cope with...

openssl-users>   * Do nothing, let the applications adapt or stick with older
openssl-users> libraries?

I don't see this as acceptable.  Let's remember that 1.1.0 -> 1.1.1 is
a *minor* upgrade, i.e. should be a drop-in backward compatible
replacement.  If that upgrade causes applications to suddenly stop
working because we're force feeding them TLSv1.3, then we've failed
that technical promise.  If I was a user in that scenario, I'd be
furious.

openssl-users>   * Something else?

Making this a *major* upgrade, i.e. 1.2.0.

openssl-users> We don't have much time before release, what do we do?

If we can't resolve this, there is the option of delaying the
release.  The release strategy is clear on this: "This may be amended
at any time as the need arises."
(https://www.openssl.org/policies/releasestrat.html)

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
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)

2018-04-19 Thread 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)

2018-04-19 Thread 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