On Tue, Sep 28, 2021 at 1:13 PM Eric Orth <[email protected]> wrote:
> > > On Tue, Sep 28, 2021 at 6:09 AM Mike West <[email protected]> wrote: > >> Hey Eric! >> >> On Thu, Sep 23, 2021 at 10:36 PM Eric Orth <[email protected]> wrote: >> >>> Contact emails >>> >>> [email protected] >>> >>> Explainer >>> >>> None >>> >>> Specification >>> >>> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-07 >>> >>> Summary >>> >>> Query DNS for HTTPS records (alongside traditional A and AAAA queries). >>> When a website has deployed an HTTPS DNS record and Chrome receives it, >>> Chrome will always connect to the website via HTTPS. >>> >>> Design doc for all Chrome DNS HTTPS plans: >>> https://docs.google.com/document/d/1k461sRbddjDGj7Q8f-ZKHZvmB-ENUWSdX_3Fpp2dmXQ >>> >>> This feature covers just the basic query and HTTP->HTTPS upgrade part of >>> those plans, and only for simpler cases that do not require followup DNS >>> queries by the Chrome DNS stack. >>> >>> >>> Blink component >>> >>> Internals>Network>DNS >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3EDNS> >>> >>> TAG review >>> >>> Not applicable. No direct changes to web platform APIs. Change is to >>> underlying DNS infrastructure, following an IETF spec, with only indirect >>> web-facing side effects. >>> >> >> This seems like an overly narrow take on the feature: it seems like this >> needs to be wired up to Fetch in order to explain how the DNS assertion >> turns into a decision about how to connect to sites (similar to HSTS's >> integration >> <https://fetch.spec.whatwg.org/#:~:text=Set%20request%E2%80%99s%20current%20URL%E2%80%99s%20scheme%20to%20%22https%22>), >> and that upgrade will have web-visible impacts. >> > > Seems accurate to me. All the signals and triggering happen in DNS, > outside web platform APIs, with no direct web-platform-API interaction, > e.g. a header like was done for HSTS. Then the result is a redirect, which > yes, is web-visible, hence the "indirect web-facing side effects". > > But I think you are right that this should get at least a mention in the > Fetch spec, and I think the ideal situation would be a single additional > sentence in that point about HSTS upgrade ("[...] or a DNS lookup for the > request's current URL per [link to section 8.5 of SVCB RFC] returns an > HTTPS DNS record." or something like that). Does that sound reasonable to > you, or do you think this will take more comprehensive updates to Fetch? > > >> Can I assume that you'll be following the same algorithm (e.g. shifting >> from 80 to 443 by switching the protocol, but not altering non-standard >> ports)? >> > > Correct. Non-standard ports result in a redirect to https with the same > non-standard port. Also noteworthy that non-standard ports would require > the HTTPS DNS record to be specific to that non-standard port, e.g. if the > request URL were "http://example.com:1234";, the redirect will only happen > if there is an HTTPS record for DNS queries for "_1234._https.example.com", > not merely at "example.com" as would be sufficient if the request URL > were "http://example.com[:80]";. > > >> >> TAG review status >>> >>> Not applicable >>> >>> Risks >>> >>> Interoperability and Compatibility >>> >>> Not directly part of the web API surface; only has indirect behavior >>> implications on the web platform in the form of the HTTP->HTTPS redirect >>> triggered by DNS signals. >>> >>> HTTPS DNS records are a feature of DNS. The spec is a draft of the IETF >>> DNSOP working group, and while not yet a published RFC, it is widely >>> considered stable and ready for implementation. IANA has designated HTTPS >>> as DNS resource record type 65. >>> >>> >>> Gecko: No signal >>> >>> WebKit: Safari has been querying HTTPS DNS records since late 2020. >>> Unclear if Safari has yet implemented HTTP->HTTPS redirect behavior of such >>> records. >>> >> >> It would be helpful to ask both Gecko and WebKit developers for more >> clear signals as described in https://bit.ly/blink-signals. >> > > Okay. I'll send off those requests. > Update: Request for position sent for WebKit: https://lists.webkit.org/pipermail/webkit-dev/2021-September/031991.html For Gecko, I discovered an older but very relevant "worth prototyping" position (https://mozilla.github.io/standards-positions/#dnsop-svcb-httpssvc) for the overall HTTPS record draft. I've updated the chromestatus entry with this position and added a note that Firefox engineers have since stayed involved in the IETF discussions. > > >> >>> Web developers: No signals >>> >> >> Are there any folks lined up to use this? Presumably there are if Safari >> is already making these queries? >> > > Most of the general interest I have heard for HTTPS records is for the ECH > and upgrade-to-QUIC functionalities that are not part of this specific > planned launch. So it would be fair to say there is a lot of interest from > various parties for HTTPS record support in general, and this HTTP->HTTPS > redirect functionality is a part of that standard, and it is by design that > you cannot get those other functionalities without also getting the > HTTP->HTTPS functionality. > > >> >> >>> Debuggability >>> >>> No specific DevTools support. Changes not directly part of the web API >>> surface. Chrome is not generally used as a development tool for changing >>> DNS records besides testing/developing the indirect behavior effects on >>> visiting websites. >>> >> >> We represent HSTS to developers in devtools. Presumably we'd want to do >> the same for this mechanism, and signal in some way to developers _why_ a >> particular request was upgraded? >> > > I wouldn't describe it as rising to the level of "support", but > DNS-triggered redirect will display similarly to other artificial redirect > responses, e.g. HSTS or extension delegates. That is that DevTools will > show a 307 redirect response with a "Non-Authoritative-Reason" field with a > short string to describe the reason, e.g. "HSTS", "delegate", or for > DNS-triggered redirects, "DNS". I've added a note on this into the the > chromestatus entry. > > >> >> >>> >>> >>> Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>> ? >>> >>> No >>> >>> Flag name >>> >>> None >>> >>> Requires code in //chrome? >>> >>> False >>> >>> Tracking bug >>> >>> https://crbug.com/1206455 >>> >>> Launch bug >>> >>> https://crbug.com/1206460 >>> >>> Estimated milestones >>> >>> Desktop 96 >>> >>> Android 96 >>> >>> Link to entry on the Chrome Platform Status >>> >>> https://www.chromestatus.com/feature/5485544526053376 >>> >>> This intent message was generated by Chrome Platform Status >>> <https://www.chromestatus.com/>. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "net-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcEJF4%3D7zU16oki_m0vYqfX2_%2BXgH2Fxf51RnMv9ipx63w%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcEJF4%3D7zU16oki_m0vYqfX2_%2BXgH2Fxf51RnMv9ipx63w%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMOjQcH4nkQuyH4TxsMoHOXRqLSOLrxNkQv0WYTt2d7LC98VgA%40mail.gmail.com.
