Hanno Böck <hanno(_at_)hboeck(_dot_)de>:
I think this adds further evidence that adding another workaround layer
(SCSV) is the wrong thing to do. Instead browsers should just stop
doing weird things with protocols that compromise security and drop
the protocol dance completely.
They shouldn't have to do the downgrade dance (and indeed
draft-ietf-tls-downgrade-scsv-03 does say so), and certainly I'll be very
glad if it turns out that now they really won't have to, but I wouldn't
hold my breath.
Ideally, the server-side TLS_FALLBACK_SCSV logic will be present as dormant
code that never gets executed (because clients just don't do those
fallbacks), but which is available if and when needed again.
I hope that the Firefox change will make it into the release channel and
survive there, but note that it doesn't actually remove the downgrade dance
entirely. Rather, there's now a setting that controls whether the downgrade
dance is enabled (https://bugzilla.mozilla.org/show_bug.cgi?id=1083058),
and the plan merely is to disable this by default (
https://bugzilla.mozilla.org/show_bug.cgi?id=1084025). Also, you may be
able to enable the kludge on a per-domain basis (
https://bugzilla.mozilla.org/show_bug.cgi?id=1114816).
There's still a lot that can happen here. If the change works well enough
for the Firefox release channel (and for all other browsers), I still
expect that a bunch of users will need to enable the downgrade dance to get
HTTPS connections to legacy devices on their local networks to work. Then
it would be discomforting to not have TLS_FALLBACK_SCSV support in servers.
Also, quite clearly, we can't yet know how the TLS 1.3 (1.4, 1.5, ...)
rollout will work out.
Bodo