Defer disabling TLS 1.0/1.1 by default?

[Colm MacCárthaigh]

You've got a great point that this is ultimately about product
management. I think if the change is just postponed, the needle won't
move much on its own, it is like kicking a can down a road. I'm sure
that there's an organic rate of decline, but it's likely quite slow.

On the current path (changing the default set) I suspect what would
happen is that the change will get caught in inter-op testing, or it
will cause some outages, and either way the operators will do some
googling and revert the default set. I doubt it will nudge many of
them to finally remove a legacy hardware appliance or whatever is
sticking them on TLS1.0/1.1 (we know it isn't Java keeping them on
it). They'll probably just go back to business and usual and leave it
like that until a compliance standard or auditor really makes them
change. I'm not sure it achieves much ... which seems dissatisfying
for a change that will probably cause outages.

This is why I'd much rather add a measurement of TLS1.0 / 1.1 usage.
Today it's hard to measure these; you can run tcpdump and figure it
out but that's not a great option for a lot of environments. So often
they have no idea how much traffic may be using it, just guesses. I
sent a link to my email to a few people I know in the security
industry and so far their estimates of usage here are actually much
higher than mine, maybe even tens of per-cents. That's a lot of
uncertainty for me. I feel like with a measure in hand, a number they
could get out of their JVM, there'd be a tool we could all use to a)
better measure impact and b) better drive results. Does RedHat have
any visibility or numbers here? If there were firm data, we could just
resolve this easily, but absent data I always prefer to assume the
worst than the hope for the best.

I never think it's too late for a good idea. But it is bad timing,
none of these changes were on my radar until a few weeks ago - it
never occured to me that we would consider making a breaking change
here right now. Coming back to product management, one of our
principles of product management at AWS is that we never break
customers or change an APIs behavior if we can avoid it, and that's
what major version updates are for. Security is an exception to that,
we do make breaking changes for security reasons when necessary, but
this is definitely a case where personally I'd avoid making any
breaking change until the data is there to show that the impact will
be negligible.

On Mon, Apr 5, 2021 at 8:52 AM Martin Balao <mbalao at redhat.com> wrote:
>
> Hello,
>
> Thanks @Colm and @Bernd for raising these well-founded concerns.
>
> We at Red Hat are already disabling by default TLS 1.0 and 1.1 in our 8
> & 11 OpenJDK builds. This is because of our strict security posture and
> a unified crypto policy management in RHEL, that goes across different
> products and libraries. Users can still re-enable these protocols making
> fairly easy configurations.
>
> I believe we will be more or less on the same side in regards to the
> technical arguments, the security assessment and the risks taken by
> keeping these protocols enabled. There is always a chance that something
> unknown emerges and old protocols are more likely to be affected. But
> it's clear that there is not an imminent, publicly-known and critical
> security risk at this moment; and, thus, the reason why the change was
> on Oracle's JDK crypto-roadmap since 2019 and has been postponed before
> [1]. It's the same discussion that browsers and other libraries/runtimes
> are having.
>
> I see this more of a product-management discussion. The protocols are
> old enough and, due to increasing security risks, need to be removed
> from a default configuration at some point. There will be users
> affected, always, and particularly with protocols so widely used in the
> past. I hope we are all on the same page there. The question is about
> timing and the balance between 1) the current security risk, 2) how many
> users will upgrade their applications in an extra time-frame if we
> postpone the change, and 3) how disruptive would be for a user to change
> a configuration property for backward compatibility.
>
> While I acknowledge that the change will disrupt some users, I tend to
> take that as part of the risk of keeping legacy systems running in
> production environments. With this change announced in advanced, I don't
> see it more disruptive than when OpenJDK vendors deprecate support for a
> legacy OpenJDK release and users are forced to upgrade. Contrary to
> that, there is backward compatibility workaround that looks fairly
> reasonable -users are already familiar to changing security properties-.
>
> I believe we are late on the release cycle to postpone now. I wouldn't
> have opposed if there were general agreement and a new target date later
> this year; but I personally think that, in terms of the disruption
> caused, the gain won't be significant.
>
> Martin.-
>
> --
> [1] - https://java.com/en/jre-jdk-cryptoroadmap.html
>


-- 
Colm