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/ > >> >> >>> >>>> 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 "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/CAKhd1E2PwcB-UOengO3r5nWax%3DbSRdTRpDjMCTByaUtz3Vd1ww%40mail.gmail.com.
