Acknowledge interaction with draft-ietf-dnsop-svcb-https scheme redirect

[ericorth]

Chrome is preparing to launch the feature from draft-ietf-dnsop-svcb-https-07 Section 8.5 that http:// requests get redirected to https:// on discovery of a matching HTTPS RR in DNS. Firefox seems to have already recently lauched this feature (see https://www.mozilla.org/en-US/firefox/92.0/releasenotes/).

I think Fetch needs to be updated to acknowledge this behavior, similar to the references to HSTS. Particularly, I think Section 4.9, point 9, (the text currently describing the HSTS redirection) needs a simple sentence or two of "or" explanation citing draft-ietf-dnsop-svcb-https and explaining when that causes the scheme to be changed to "https".

I can take a stab at a PR for this next week if there's general agreement that this is the right way to go to account for this new behavior.

[annevk]

It seems like we should also update https://fetch.spec.whatwg.org/#resolve-a-domain to indicate it can return more than just IP addresses?

Is this restricted to DoH lookups? (Not sure that needs to be mentioned though. Perhaps in a note.)

There's also #920 which we haven't solved yet. Presumably similar concerns apply to this feature.

[ericorth]

It seems like we should also update https://fetch.spec.whatwg.org/#resolve-a-domain to indicate it can return more than just IP addresses?

Makes sense. We can probably keep it pretty vague and implementation-defined like the current text there.

Is this restricted to DoH lookups? (Not sure that needs to be mentioned though. Perhaps in a note.)

Not necessarily. The IETF spec doesn't limit things either way. For Chrome, we're still internally debating whether our initial launch will be DoH-only or all-DNS, but there's certainly a desire long-term for non-DoH handling of HTTPS record.

There's also #920 which we haven't solved yet. Presumably similar concerns apply to this feature.

Actually, I don't think that vulnerability or similar applies to DNS-based redirect. I think the key difference is that HSTS connects to the server differently between the first connection and subsequent connections, allowing the server to easily see whether or not the browser had it in its HSTS cache. DNS-based redirect occurs from the first connection, so whether or not the browser has recently connected, all the server sees is the https:// connection.

The only similar vulnerabilities I can think of here are DNS cache "cookies" through timing or direct observation of the DNS traffic to determine if the browser had the HTTPS record in its DNS cache. But that's all just as vulnerable with A/AAAA requests, with or without HTTPS queries, so nothing there specific to the redirect feature.