accept insecure TLS state seems badly specified

https://w3c.github.io/webdriver/#dfn-post-navigation-checks contains:

response is blocked by content security policy

If the remote end's accept insecure TLS state is true, take implementation specific steps to ensure the navigation is not aborted and that the untrusted or invalid TLS certificate error that would normally occur under these circumstances, are suppressed.

Otherwise return error with error code insecure certificate.

This seems to originate from https://github.com/w3c/webdriver/commit/321fff4e12d80a745828f7c711fdc18932cca244 (from https://github.com/w3c/webdriver/pull/337).

As far as I can tell, what we're actually trying to override is the nebulous "if establishing a connection does not succeed (e.g., a UDP, TCP, or TLS error), then return failure" in https://fetch.spec.whatwg.org/#create-a-connection which ultimately gets surfaced as a network error. Fetch calls into the CSP to determine whether or not certain requests should be blocked, but TLS connection errors aren't one of them.

This should presumably be under "response is a network error" instead.

However, this doesn't make sense to have as a post-navigation step.

If Fetch is failing with a network error while it is creating a connection, it is not even reaching a point of actually making an HTTP request. Thus while navigation will complete, it will have already hit the network error when creating the connection. It is unclear how after the navigation (assuming it hasn't timed out) the implementation can "take implementation specific steps to ensure the navigation is not aborted and that the untrusted or invalid TLS certificate error that would normally occur under these circumstances, are suppressed".

Start with the post-navigation checks section and the cited Fetch create-a-connection algorithm, then review commit 321fff4 and pull request 337. Determine where accept insecure TLS behavior belongs and define the expected navigation outcome; the specification should state this behavior unambiguously.