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/CAKXHy%3DfCreHgWwWhA3GSBcSDd8qDQYq1MxFt68N2BOyMfEd6dg%40mail.gmail.com.
