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

[Bernd Eckenfels]

Hello,

I would expect that Oracle will include the new JSSE provider in their PSU but not in their CPU release. And since at least Azul also follows that convention, why not make this a OpenJDK Release as well (i.e. the opposite of the below mentioned sequence, release 8uN without TLS changes and N+1 as well as (later) N+10 with the backport.

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> im Auftrag von Martin Balao <mbalao at redhat.com>
Gesendet: Tuesday, June 16, 2020 6:48:45 AM
An: jdk8u-dev at openjdk.java.net <jdk8u-dev at openjdk.java.net>
Cc: Pavel Petroshenko <pavel at azul.com>; Gil Tene <gil at azul.com>
Betreff: Re: [8u] TLS 1.3: fallback scheme for the new SunJSSE engine

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

We are on the same page, then.

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

Let me clarify a bit the idea, because there is some misunderstanding. I
was not proposing to release or maintain both builds: only one at a time.

The 8u repository will have the new TLS engine pushed. We can release
8u272-build-<N> with new TLS engine and have 8u272-build-<N+1> with the
old TLS engine ready but unreleased.

If thing go okay, 8u272-build-<N+1> will be dropped without being ever
published.

If things go wrong -to the point that we have a major/blocker issue that
cannot be quickly resolved-, we release 8u272-build-<N+1> immediately as
the successor of 8u272-build-<N>.

That would give us 3 months to fix the problem and release 8u282 with
the new TLS engine.

Note: there cannot be much time between 8u272-build-<N> and
8u272-build-<N+1> because even if the change should be transparent for
most of the users, some of them may need to modify their applications
for backward compatibility.

I see a couple of downsides:

1) As @gnu_andrew pointed out, there may be dependencies that make
'backing out the new TLS engine patches' to generate build-<N+1> not
that trivial.

2) We need to somehow publish the source code upon which
8u272-build-<N+1> was built for license compliance reasons.

Regards,
Martin.-