What firewall are you using? We've seen a number of buggy firewalls, and while most have distributed fixes, there are a couple that need manual adjustment (until they get a patch out).

It would also be helpful to get a net-internals log when you reproduce the issue, see details here:
https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

Thank you for the quick response. The Firewall is a Watchguard Firebox. They haven't fully implemented TLS1.3 yet. The current Firmware identified TLS1.3 traffic as SSL traffic but content inspect of this fails. This is expected on the Firebox. 

The current TLS1.3 draft has not been finalised so I'm surprised there is no failback to 1.2 that is automated in Chrome. If a automatic failback is expected then I'm happy to provide logs. If failback to 1.2 is not expected then this is working as expected since Watchguard apreas to be waiting for a final TLS1.3 draft before full support for TLS 1.3 is applied.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The issue seems to be out of scope for triaging it from ET end as this speaks about install a Firewall with HTTPS content inspection, hence adding label TE-NeedsTriageHelp and requesting someone from "Internals>Network>SSL" team to have a look into it and help in further triaging it.

Thanks!

Do you know what version of Watchguard is being used?

The lack of fallback is intentional, though we've previously done testing with Watchguard and didn't have issues from their products in our deployment attempt in December, so it sounds like something has changed since then. Possibly one of their recent updates broke things.

To clarify the fallback business, a bit, as "fallback" is a bit ambiguous of a word.

TLS 1.3, both the draft and final versions, are fully backwards-compatible with TLS 1.2. A compliant TLS 1.2 client can connect to a TLS 1.3 server and a TLS 1.3 client can connect to a compliant TLS 1.2 server. They will securely negotiate TLS 1.2, as that is the highest mutual version. In that sense, there is a downgrade-protected fallback to TLS 1.2.

What there isn't is an unsecured fallback to TLS 1.2. That is, we do not work around buggy TLS 1.2 implementations which do not version negotiation correctly. That is intentional to avoid security issues like what previously exacerbated the POODLE vulnerability.

This issue suggests that something on your network, perhaps the Watchguard device, is non-compliant and did not implement TLS 1.2 correctly. There is no requirement that devices on your network implement TLS 1.3 yet. They certainly should when that is ready, as TLS 1.3 is a significant improvement over TLS 1.2, but ERR_SSL_VERSION_INTERFERENCE comes from mistakes in TLS *1.2* implementations.

Are you still running into this issue? If so, what version of Watchguard is being used, per comment #6?

Closing due to lack of feedback. Please feel free to file a new issue if you're still running into this.