+1 to Mike's request. I think a Fetch PR for this seems both useful and not-extremely-onerous to pull together.
On Thursday, September 30, 2021 at 9:20:23 PM UTC+2 Mike West wrote: > This all looks good, thanks. > > I'd like to see the Fetch PR up before we ship this. It's a little > surprising that neither WebKit nor Gecko wired that up, but if we have > three interoperable implementations, it should be quite straightforward to > specify. > > I also wonder a little about WPT; we should probably at least file a ` > type:untestable > <https://github.com/web-platform-tests/wpt/issues?q=is%3Aissue+is%3Aopen+label%3Atype%3Auntestable>` > > issue to point to this as something that's not feasible to validate without > additional WebDriver support. > > -mike > > > On Thu, Sep 30, 2021 at 4:42 PM Eric Orth <erico...@chromium.org> wrote: > >> >> >> On Thu, Sep 30, 2021 at 6:53 AM Kaustubha Govind <kaustub...@chromium.org> >> wrote: >> >>> >>> >>> On Tue, Sep 28, 2021, 2:08 PM Eric Orth <erico...@chromium.org> wrote: >>> >>>> >>>> >>>> On Tue, Sep 28, 2021 at 1:13 PM Eric Orth <erico...@chromium.org> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Tue, Sep 28, 2021 at 6:09 AM Mike West <mk...@chromium.org> wrote: >>>>> >>>>>> Hey Eric! >>>>>> >>>>>> On Thu, Sep 23, 2021 at 10:36 PM Eric Orth <erico...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> Contact emails >>>>>>> >>>>>>> erico...@chromium.org >>>>>>> >>>>>>> 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. >>>> >>> >>> FYI, it appears that Firefox 92 performs the http->https upgrade with >>> HTTPS DNS records (i.e. the exact feature that this thread is discussing): >>> >>> https://www.mozilla.org/en-US/firefox/92.0/releasenotes/ >>> >> >> Updated the chromestatus entry. Thanks. >> >> >>> >>> >>>> >>>>> >>>>> >>>>>> >>>>>>> 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 net-dev+unsubscr...@chromium.org. >>>>>>> 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 "net-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to net-dev+unsubscr...@chromium.org. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcH4nkQuyH4TxsMoHOXRqLSOLrxNkQv0WYTt2d7LC98VgA%40mail.gmail.com >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcH4nkQuyH4TxsMoHOXRqLSOLrxNkQv0WYTt2d7LC98VgA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> 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 net-dev+unsubscr...@chromium.org. >> > To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcFFMkuhWjP-cMg%2BAH_Sr_DdHESEowQgDkh_tnF7Fy1t8A%40mail.gmail.com >> >> <https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcFFMkuhWjP-cMg%2BAH_Sr_DdHESEowQgDkh_tnF7Fy1t8A%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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fb81b56b-e5f6-4f36-aac5-25bdb1ce0c45n%40chromium.org.
