Hanno Böck <hanno@xxxxxxxxx>:
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