Re: [whatwg/fetch] Acknowledge interaction with draft-ietf-dnsop-svcb-https scheme redirect (#1325)

@davidben commented on this pull request.



> @@ -3873,11 +3884,16 @@ steps:
    <li>Matching <var>request</var>'s <a for=request>current URL</a>'s <a for=url>host</a> per
    <a href=https://datatracker.ietf.org/doc/html/rfc6797#section-8.2>Known HSTS Host Domain Name Matching</a>
    results in either a superdomain match with an asserted <code>includeSubDomains</code> directive
-   or a congruent match (with or without an asserted <code>includeSubDomains</code> directive).
-   [[!HSTS]]
+   or a congruent match (with or without an asserted <code>includeSubDomains</code> directive) or
+   DNS resolution for the request finds a matching HTTPS RR per
+   <a href=https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https#section-8.5>HTTP Strict Transport Security</a>.
+   [[!HSTS]][[!SVCB]]

> I think in practice these days HSTS upgrades only end up happening for navigation so the same origin check ends up not being applicable.

I don't believe that's true. At least in Chromium, HSTS upgrades happen in the net stack, across all requests. It's true that navigations are the [most important cases](https://github.com/mikewest/strict-navigation-security/blob/master/README.md), and mixed content blocking makes a lot of it moot, but not all. For instance, if http://example.com has an http://has-hsts.example subresource, HSTS will apply.

> But perhaps changing request's URL directly is also problematic. At least it doesn't seem great in hindsight.

Right, this is why Chromium synthesizes a redirect instead. Too many parts of the browser, from mixed content checks to CORS to developer tools to extensions, get confused when URLs change underneath them. Indeed our internal HTTP APIs cannot URLs without synthesizing a redirect. I cannot imagine us switching away from a synthesized redirect, here or HSTS.

Could you elaborate on the bugs from synthesizing a redirect?

> Presumably these DNS records also only come into play when navigating so changing the scheme around the time of establishing a connection would be okay.

No, they come into play for all requests. Architecturally, I don't think it would be feasible to make them navigation-only. Nor would it be desirable because these records also carry [ECH keys](https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-13), how to connect via HTTP/3, a fix for the CNAMEd apex problem, and some Alt-Svc-like features. They'll likely be extended in the future to deliver other network-related information. (Due to how DNS works, related to your question below, most metadata needs to be glommed together into one record for scenarios like multi-CDN to work right.)

> Are HTTPS RR records obtained as part of the normal DNS call or are these separate requests?

I'm not sure what you mean by this. They are separate record types, so conceptually different queries. But, in the limit, the exact dance can be complicated between resolvers reporting additional records, net stacks that do and don't implement Happy Eyeballs v2, Alt-Svc, etc. I'm not sure the infrastructure is in place yet to really pin this down in Fetch.

I think this also is part of where the boundary between Fetch and protocol specifications is not very clear. There's a lot of stuff that happens in the process of making an HTTP request that's not covered by Fetch, and rightfully so. We don't want to have to copy the entirety of HTTP/1.1, HTTP/2, HTTP/3, and TLS into Fetch. It's already specified there, and not web-platform-specific.

At the same time, the web platform *does* have very specific opinions on state management and which requests are and aren't correlatable. So I think the right division would be for Fetch to defer the low-level protocol specs, but talk about contexts for partitioning state. And, conversely, the low-level protocol specs should do a better job of defining their "public API" w.r.t. what state there is to partition across contexts.

Indeed, I'd argue that ideally the HTTPS record wouldn't appear in Fetch at all. It's part of the protocol-internal machinery between HTTP versions, connection setup, DNS, and TLS. Unlike HSTS, we don't need to hook into Fetch for any state. All state it affects is already covered by DNS caches and connection pools, which ideally Fetch could describe generically. This way we minimize unnecessary churn, and avoid problems where some bit of state is missed because Fetch was too specific, or Fetch contradicts reality by overspecifying some since updated networking protocol.

Of course, we're far from that ideal right now. Until that's all worked out, browsers are still [shipping networking features](https://www.mozilla.org/en-US/firefox/92.0/releasenotes/), so I think something like this PR, which acknowledges the existence but doesn't try to duplicate everything, is the way to go.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1325#discussion_r729287918