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

@annevk 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. Having said that, doing it in terms of a redirect that doesn't end up affecting the security properties seems like quite a challenge and has historically been a source of bugs in implementations.

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

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.

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

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