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

[Martin Balao]

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