Issue says OS is Mac. It is in fact Windows 10.

This is likely due to a buggy middle-box on your network blocking newer versions of TLS (TLS 1.3). Do you know if you have any anti-virus/proxy/firewall products installed that might be causing issues?

Using windows defender.
No Firewall / proxy 
Direct to ISP https://www.plus.net

Works fine with edge & FF 58.0.2

 ➤ tracert sbs-ak.naic.org

Tracing route to sbs-ak.naic.org [8.33.1.215]
over a maximum of 30 hops:

  1     4 ms     6 ms     4 ms  BTHUB [192.168.1.5]
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4    11 ms    12 ms    11 ms  be3-3104.psb-ir01.plus.net [195.166.143.136]
  5    11 ms    11 ms    10 ms  core1-BE1.southbank.ukcore.bt.net [195.99.125.130]
  6    12 ms    15 ms    13 ms  peer6-hu0-6-0-6.telehouse.ukcore.bt.net [195.99.127.3]
  7    12 ms    12 ms    11 ms  t2c3-et-8-1-0-0.uk-lon1.eu.bt.net [166.49.211.240]
  8    12 ms    12 ms    12 ms  hu0-6-0-4.ccr22.lon01.atlas.cogentco.com [130.117.14.65]
  9    12 ms    12 ms    12 ms  be2869.ccr42.lon13.atlas.cogentco.com [154.54.57.161]
 10    80 ms    80 ms    79 ms  be2983.ccr32.bos01.atlas.cogentco.com [154.54.1.178]
 11    81 ms    80 ms    80 ms  be2302.ccr22.alb02.atlas.cogentco.com [154.54.43.14]
 12    93 ms    90 ms    91 ms  be2879.ccr22.cle04.atlas.cogentco.com [154.54.29.173]
 13    98 ms    98 ms    99 ms  be2718.ccr42.ord01.atlas.cogentco.com [154.54.7.129]
 14   118 ms   118 ms   118 ms  be2832.ccr22.mci01.atlas.cogentco.com [154.54.44.169]
 15   123 ms   123 ms   123 ms  be2607.rcr21.tul01.atlas.cogentco.com [154.54.31.97]
 16   123 ms   124 ms   123 ms  be2704.rcr21.okc01.atlas.cogentco.com [154.54.7.233]
 17   119 ms   119 ms   119 ms  te0-0-2-0.nr11.b015067-1.okc01.atlas.cogentco.com [154.24.39.150]
 18   133 ms   133 ms   131 ms  38.104.87.194
 19     *        *        *     Request timed out.
 20     *        *        *     Request timed out.
 21     *        *        *     Request timed out.
 22     *        *        *     Request timed out.
 23     *        *        *     Request timed out.
 24     *        *        *     Request timed out.
 25     *        *        *     Request timed out.
 26     *        *        *     Request timed out.
 27     *        *        *     Request timed out.
 28     *        *        *     Request timed out.
 29     *        *        *     Request timed out.
 30     *        *        *     Request timed out.

Trace complete.

It looks like the web server being used by the site breaking when talking with a TLS 1.3 client, instead of negotiating TLS 1.2, either due to some proxy/middlebox on their network or due to a badly configured server.

To verify, can you connect to https://tls.ctf.network/version.php and verify it says you are connecting with TLS 1.2 or TLS 1.3 Draft 23.

You are connecting with TLSv1.3 Draft 23.

If I disable TLS 1.3 from chrome://flags/
then https://sbs-ak.naic.org/Lion-Web/jsp/sbsreports/AgentLookup.jsp responds as expected 

Yeah, it sounds like this is an issue with their server/network. If you have a contact with the company, then letting them now or linking this bug might be helpful to get an idea of what part of their server is at fault.

It is a USA government website that I dont have contact with

Using ssl labs https://www.ssllabs.com/ssltest/analyze.html?d=sbs-ak.naic.org

Shows they only support draft 18

Protocols
TLS 1.3	No
TLS 1.2	Yes
TLS 1.1	Yes
TLS 1.0	Yes
SSL 3	No
SSL 2	No
For TLS 1.3 tests, we currently support draft version 18.

I will leave chrome TLS1.3 support disabled.

I've reached out through their support link on the naic.org website, so hopefully they'll respond through that.

Ah. That might be ssl labs that only supports up to draft 18.
Looks like the *naic.org site doesn't support TLS 1.3

Yeah, most websites don't support TLS 1.3 currently, however almost all servers correctly negotiate TLS 1.2 (since TLS is a versioned protocol) when they're presented with a TLS 1.3 capable client, it seems for some reason the sbs.naic.org site instead critically fails.

svaldez: I'm actually not able to reproduce this issue on my machine in either Chrome or BoringSSL command-line client. Were you able to reproduce this?

Hmm, I was able to reproduce it yesterday, however it seems to no longer be erroring out for me, its possible it was a transient issue on their server?

Maybe they've fixed whatever was wrong?

alan: Are you still experiencing the issue? If not, I guess we can just close this and reopen if it comes back.

Still getting it - see screenshot for https://sbs-ak.naic.org/Lion-Web/jsp/sbsreports/AgentLookup.jsp 
Sometimes it times out and sometimes the domain doesn't get resolved.

Deleted: ERR_SSL_VERSION_INTERFERENCE2.png 155 KB

	ERR_SSL_VERSION_INTERFERENCE2.png 155 KB View Download

BTW I'm quite happy to use FF or disable TLS1.3 for access to these sites. So you can close if you think the issue is with naic.org.

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

Hrm, weird. Well, if it's a TLS 1.3 issue, it will break in Firefox and other browsers in the future too, as other browsers adopt TLS 1.3, presuming they don't implement an insecure version downgrade. So we should get to the bottom of this.

I noticed that the NetLog you attached back in comment #2 shows naic.org waiting 26 seconds before reseting the connection on a TLS 1.3 ClientHello. That suggests something is timing out somewhere. Is that always the case when you get ERR_SSL_VERSION_INTERFERENCE, or do you sometimes get that instantly?

You also mentioned that sometimes the request times out overall. That makes me wonder if ERR_SSL_VERSION_INTERFERENCE is a red herring and really you're just seeing intermittent timeouts at that server for some reason. (ERR_SSL_VERSION_INTERFERENCE means the TLS 1.3 ClientHello, which is also good for TLS 1.2, failed but a retry with TLS 1.3 off succeeded. If the server is just flaky, we will incorrectly diagnose the problem as a TLS 1.3 issue if the first connection happened to fail and the second succeed.)

(I tried replaying the exact ClientHello in the NetLog and also wasn't able to reproduce the issue.)

Q.Is that always the case when you get ERR_SSL_VERSION_INTERFERENCE, or do you sometimes get that instantly? 
A. always ~30s to wait for error.

Thought I'd try beta & canary in guest mode to discount any interference from my extensions.

Version 66.0.3359.45 (Official Build) beta (64-bit) => ERR_SSL_VERSION_INTERFERENCE

Version 67.0.3377. (Official Build) canary (64-bit) => Correct form rendered instantly.

Canary had an update pending
Version 67.0.3378. (Official Build) canary (64-bit) => ERR_CONNECTION_RESET (after 30+seconds)

All 3 versions had TLS 1.3 flag = default.
Multiple tests on each version all consistent result

Deleted: chrome-net-export-log_67.0.3378.0_canary.json 188 KB

chrome-net-export-log_67.0.3378.0_canary.json 188 KB View Download

Deleted: chrome-net-export-log_67.0.3377.0_canary.json 185 KB

chrome-net-export-log_67.0.3377.0_canary.json 185 KB View Download

Deleted: chrome-net-export-log_66.0.3359.45_Beta.json 125 KB

chrome-net-export-log_66.0.3359.45_Beta.json 125 KB View Download

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

Firefox also fails to connect to those sites when forced to use TLS1.3 by setting security.tls.version.max to 4 in about:config
Firefox supposedly uses Draft 18.

correction: security.tls.version.min

Curl isn't to happy either from Ubuntu 16.04.4 LTS

root@f48178b67494:/# curl -vvv -H 'User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko' https://sbs.naic.org/solar-external-lookup/
*   Trying 165.103.1.231...
* Connected to sbs.naic.org (165.103.1.231) port 443 (#0)
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 592 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* gnutls_handshake() failed: The TLS connection was non-properly terminated.
* Closing connection 0

Using --no-alpn
root@f48178b67494:/# curl --no-alpn -vvv -H 'User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko' https://sbs.naic.org/solar-external-lookup/
*   Trying 165.103.1.231...
* Connected to sbs.naic.org (165.103.1.231) port 443 (#0)
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 592 certificates in /etc/ssl/certs
* SSL connection using TLS1.2 / DHE_RSA_AES_256_GCM_SHA384
* server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
* Closing connection 0
curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

If even curl doesn't work, that suggests it's nothing to do with TLS 1.3 or Chrome and either your network or their server is flaky. curl doesn't use the same network stack as Chrome or anything.

Can you see why 67.0.3377 worked?
IMO if a sites baulks at a tls1.3 attempt then the browser should ingore that and go ahead with 1.2. 

67.0.3377.0 also has TLS 1.3 enabled, and I don't believe we made any changes between there. So that further suggests it's not TLS-1.3-related. Note curl also does not do TLS 1.3 yet. Again, ERR_SSL_VERSION_INTERFERENCE is likely a red herring. The way that error code works, if things are flaky, you may get false positives.

No, it's not correct to retry at TLS 1.2 if sites break on TLS 1.3 ClientHellos. That would introduce a security vulnerability; see POODLE. TLS versioning works differently. A TLS 1.3 ClientHello is *also* a TLS 1.2 ClientHello, and a TLS 1.1 ClientHello, and every older version the browser supports. A correct TLS 1.2 server will process a TLS 1.3 ClientHello as TLS 1.2, and indeed both your NetLog for 67.0.3377.0 and local testing suggests that server handles it just fine. In fact, we actually tweaked TLS 1.3 to work around a common bug in servers to make it more likely this'll work.

A Gentle ping.
Request to please provide an update on this issue.

Thanks!

Mac triage: network team, is this WontFix? Assigning to davidben@ for followup.

Closing due to lack of feedback.