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]]

> Although I think browsers are considering not applying HSTS there.

This is for cross-site state considerations? Yes, we've been talking about this in https://github.com/mikewest/strict-navigation-security, though it may be preferable to double-key and still apply the static list. Even with insecure-to-insecure resource sourcing, some network based attacks are easier than others and HSTS helps smooth over [chokepoints](https://github.com/mikewest/strict-navigation-security/blob/master/README.md#does-this-enable-interesting-network-based-attacks).

But this is a digression from this PR. There are no cross-site state concerns for this DNS-based upgrade. (The only state is in connection pools and DNS cache, which already need to be partitioned.) It is simpler, more secure, and more private to just apply it to all fetches uniformly.

> A problem with synthesizing a redirect that I see is that the tainted origin flag would get set, for instance. And as Mike pointed out above the same origin check wouldn't pass which means the response itself would get tainted as well. I think there's also a couple places that look at the entire request URL list at the moment, but ideally we can move all of those to use origin & tainted origin flag.

That seems, not only fine, but desirable here. This is gated on a DNS query, and DNSSEC is not really a thing, so there is actually some network dependency. This is an http URL that upgrades to https in a more robust way than an HTTP redirect (only DNS/DoH resolver can mess with it), but less robust than HSTS or specifying the HTTPS URL (DNS/DoH resolver can mess with it). Even HSTS is, itself, less robust than specifying the HTTPS URL if not preloaded.

I think we _want_ same-origin checks to take into account both two origins. Synthesizing a redirect means that reuses the existing platform mechanisms for doing so.

The IETF draft also says to synthesize a redirect:
https://mikebishop.github.io/dns-alt-svc/draft-ietf-dnsop-svcb-https.html#section-9.5

-- 
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_r733800211