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

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

-- 
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/issues/1315#issuecomment-932369818