Update: Started a Fetch PR: https://github.com/whatwg/fetch/pull/1325
On Thu, Oct 7, 2021 at 3:34 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > +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/CAMOjQcHTz_PWTUQG_7LyQORzB9s4x5AVMp9QGRTLSQADe%2B1kqA%40mail.gmail.com.
