[8u] TLS 1.3: fallback scheme for the new SunJSSE engine

[Martin Balao]

Hi,

The JDK-8 backport of the new SunJSSE TLS engine (that includes support
for TLS 1.3) is expected to land in the first 8u272 Early Access (EA)
release. As you may have already noticed, we are still in the process of
reviewing each step in which we broke down the patch.

Considering the risks associated to backporting such a critical and
complex component, we started an internal discussion yesterday about a
fallback scheme in case something goes wrong. Given that this might be
of interest and impact the whole community, we agreed on moving the
discussion to the public and encouraging everyone to participate.

What you will find below this email is a rebuild of the previous
conversation, in chronological order (from older to newer).

Thanks,
Martin.-

--

============ Gil Tene (2020-06-04) ============

On the Azul side, we are still considering including the new
implementation in a July Zulu update. We have also built a fallback JSSE
implementation, which is a "sideport" ("outport"?) of the current (now
legacy) 8u JSSE implementation and is aimed to be used as a separate,
optional jar in case there is some reason to go back to the old
functionality. We've been testing it, and will probably end up placing
it under something like org.openjsse.legacy8ujsse. I don't know if it
makes sense to add this fallback artifact to the OpenJDK 8u project
itself, but it would be useful to have it out there as an escape hatch
for people to use if 11u-driven regressions do show up.





============ Martin Balao (2020-06-04) ============

It's a hard choice. I'm more inclined not to push that into the upstream
repository. A parallel TLS engine will need to be updated regularly
-against security issues at least- and supported, increasing the
maintenance burden. The integration itself may create unexpected
trouble. In addition, we will be introducing a non-standard Security
Provider that breaks compatibility with Oracle's JDK and creates some
expectations on our users of what is available in JDK-8 (if we decide to
remove it later, we will certainly break code).

One thing that came to my mind to address this problem was having an
'emergency 8u272 build' with all the security patches applied but
without the TLS 1.3 engine. In case things go horribly wrong, we can ask
our users to use that build until 8u282.

I'm perfectly aware of the risks we are taking. With that said, I'm also
confident in the technical capabilities we have in the community to
workaround possible issues in a reasonable time.





============ Gil Tene (2020-06-04) ============

>>> On 6/4/20 3:52 PM, Martin Balao wrote:
>>> It's a hard choice. I'm more inclined not to push that into the upstream
>>> repository. A parallel TLS engine will need to be updated regularly
>>> -against security issues at least- and supported, increasing the
>>> maintenance burden. The integration itself may create unexpected
>>> trouble. In addition, we will be introducing a non-standard Security
>>> Provider that breaks compatibility with Oracle's JDK and creates some
>>> expectations on our users of what is available in JDK-8 (if we decide to
>>> remove it later, we will certainly break code).

I think that (in the balance) I agree that we don't want this fallback
provider in the project itself. The fact that we will want to quickly
deprecate and remove it (once the new stuff has been around for a while
and works well) is a good hint that we should not put it in.

But I do think that it would be useful, and it looks to be working well.
What we can do is put it up under openjsse on github, so it is ready to
go if people need it. This way it acts as interim insurance, is
available for everyone (and e.g. for distros that want to bundle it) but
does not contaminate the project with the long term legacy of a
temporary bandaid...

>>>
>>> One thing that came to my mind to address this problem was having an
>>> 'emergency 8u272 build' with all the security patches applied but
>>> without the TLS 1.3 engine. In case things go horribly wrong, we can ask
>>> our users to use that build until 8u282.

That's definitely an alternative, but it also risks the long term
bifurcation with two builds needed every quarter. i.e. of both builds
are available in 8u272, most people may choose to go with the no-new-TLS
mode to contain risk, and only people that actually want TLS 1.3 will
adopt the new builds. We will then be faced with the need to keep
building both every quarter for a while.

My hope is that offering a fallback option for use if there is a
regression, and that can be downloaded from github, would be enough to
cover the risk...

>>>
>>> I'm perfectly aware of the risks we are taking. With that said, I'm also
>>> confident in the technical capabilities we have in the community to
>>> workaround possible issues in a reasonable time.

I agree. I'm confident that we will fix whatever needs fixing. This is
just about the time between.