Intent to Experiment: Querying HTTPSSVC

[Daniel McArdle]

Contact emails

dmca...@chromium.org, eric...@chromium.org

Explainer

HTTPSSVC is a new DNS resource record that contains an extensible key-value map. With HTTPSSVC, clients can obtain pre-connection information efficiently, with just one additional DNS query.

Design doc/Spec

https://tools.ietf.org/html/draft-ietf-dnsop-svcb-httpssvc-01

(TAG review N/A. This is a new DNS record type defined in the IETF DNSOP working group, not a web platform API under the W3C.)

Summary

We plan to start experimenting with HTTPSSVC as early as M82. All HTTPSSVC behavior will be guarded behind the “dns-httpssvc” feature flag.

Goals for Experimentation

We want to assess the performance impact of querying a new DNS record. When enrolled in the experiment, and only if DNS-over-HTTPS is enabled, Chromium will query HTTPSSVC alongside the standard A/AAAA records. We will collect UMA metrics to evaluate performance and UKM metrics to study query performance and reliability in the field, particularly around handling by recursive and authoritative resolvers. Any DNS responses to HTTPSSVC queries may be inspected for experiment data, but will not be used to establish connections at this time.

In a later milestone, we plan to extend this experiment and actually use the HTTPSSVC responses to inform connection establishment. We will update this thread when that milestone approaches.

Experimental Timeline

M82-M84

Any risks when the experiment finishes?

No, at this stage of experimentation, the returned records are not used to establish connections, so there is no impact on functionality.

Motivation

In the short term, HTTPSSVC will bring privacy and performance benefits when connecting to domains for the first time.

• Currently, unless the scheme is specified, URLs typed into the browser’s address bar default to “http://”. This is mitigated by HSTS, but unless the site is covered by the HSTS preload list, this does not cover the first time a user visits a site. HTTPSSVC enables the browser to upgrade the URL scheme to “https://” without first making an insecure connection (assuming a secure connection, e.g. DoH, to a trusted DNS resolver).

• Similarly, the first connection to an origin that supports QUIC is made over TCP. If we receive an Alt-Svc header indicating QUIC, future connections will attempt QUIC. HTTPSSVC enables QUIC on the first connection to a domain.

HTTPSSVC will also enable delegation of apex domains, which CNAME is currently incapable of expressing.

In the long term, HTTPSSVC lays the groundwork for new protocols and network-level features.

Risks

Interoperability and Compatibility

Due to compatibility concerns with DNS forwarding implementations on non-updatable legacy resolvers, we are only going to query HTTPSSVC over DoH. Chrome already avoids overwhelming low-throughput DNS forwarders by limiting the number of concurrent queries made over cleartext. Adding a new query for HTTPSSVC would eat into that budget and hurt performance. It’s also a risk that these DNS forwarders will drop queries for unknown records or break in arbitrary, unpredictable ways.

Ergonomics

While HTTPSSVC exposes no API, the purpose of this experiment is to assess the performance impact of querying HTTPSSVC records. If it has a significant performance impact, some users will experience delayed page loading.

Activation

The main challenge for developers to start using HTTPSSVC is generating and serving the appropriate records for their domains. We anticipate hosting providers and CDNs will first add automatic support for this on fully-managed domains, and then add HTTPSSVC options to existing DNS configuration UIs.

Debuggability

There is currently no precedent for debugging DNS configuration in DevTools. However, we are devoting some thought to surfacing HTTPSSVC details.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

HTTPSSVC queries will only be sent over DoH connections, thus limiting support to platforms where DoH is enabled: Windows, Mac, ChromeOS and Android. 

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5948056459542528

Requesting approval to ship?

No

[Ryan Sleevi]

I realize this is very early in the experimentation phase, but linking to the spec as the design doc seems like it misses useful answers to the questions raised during this I2E. 

In reading this, my core question was trying to understand what metrics were going to be collected and how they'd be used. It seems that certainly that would be needed before the experiment is extended / the results are used, but also seems useful for understanding any gotchas, privacy considerations, potential impact on performance, etc.

Is there a public design doc, perhaps using the template, that will be updated as the experiment is fleshed out, as well as track the design strategy and what doesn't work?

[Dan McArdle]

Hi, Ryan, that's a fair point!  A design doc for this experiment is in the works.  I hope to share it here in the next few days.

[Jochen Eisinger]

Do we know whether there are sufficiently many hosts with HTTPSSVC records in DNS fo this experiment to be meaningful?

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGmnN46--%3D0hLEnsWK%2BcJyJese3AD%3D9vaViJB_LHrDFM73gRQA%40mail.gmail.com.

[PhistucK]

I have no idea how this works - sorry for the dumb question - but is there a way to query A/AAAA and HTTPSVCS records in a single query?

Otherwise this does not seem to be saving a lot (relatively), if you have to initiate another request anyway...

☆PhistucK

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+u...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CALjhuicC1od%3D8qenc0r1mZwOg_yGMgPnU_j%3DCEWCutnffY0pcw%40mail.gmail.com.

[Eric Orth]

On Wed, Feb 12, 2020 at 9:30 AM PhistucK <phis...@gmail.com> wrote:

I have no idea how this works - sorry for the dumb question - but is there a way to query A/AAAA and HTTPSVCS records in a single query?

Otherwise this does not seem to be saving a lot (relatively), if you have to initiate another request anyway...

Chrome currently queries A and AAAA concurrently as separate DNS queries.  HTTPSSVC will be made as a third separate but concurrent query.

 

☆PhistucK

On Wed, Feb 12, 2020 at 3:32 PM Jochen Eisinger <joc...@chromium.org> wrote:

Do we know whether there are sufficiently many hosts with HTTPSSVC records in DNS fo this experiment to be meaningful?

The quick answer is that at the current level of standardization (format still in flux and a type code not yet assigned) there will be almost no hosts in existence with such records and even less that Chrome could recognize as valid HTTPSSVC for the experiment.  But even when the response is always negative, we are experimentally interested in seeing how the ecosystem handles receiving and responding to the queries.  Details coming soon in the design doc dmca...@chromium.org is working on.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CABc02_J-Ak%2B14ACUtThb-ZCThk2xnAOu5j%2BYWgYE2Zo1Phy8ZA%40mail.gmail.com.

[PhistucK]

Perhaps this is a bit more of a standards question, but is there a way to query multiple types at once?

If not, is this planned?

If not, do you know why not?

☆PhistucK

[Eric Orth]

Multiple types in a single query is technically allowed by the DNS protocol, but there are subtle practical issues and it is generally unsupported by the ecosystem.  So in practice, making individual queries is just the way the modern internet works.  I believe there have been multiple attempts within standards bodies to create a workable multi-query solution, but none of those attempts have really gone anywhere.

[PhistucK]

Even in DNS-over-HTTPS? I would assume that a recent technology with recent implementations would work to improve performance as well (by supporting multiple types in a single query, for example).

☆PhistucK

[Eric Orth]

Yes, even in DNS-over-HTTPS.  DoH is primarily a transport upgrade.  The underlying protocol is still the same, with the same practical restrictions regarding combined queries.

[Yoav Weiss]

Experimenting with HTTPSSVC seems worthwhile.

Is this an intent for an Origin Trial? Or for some Finch based experiment?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcG-43s6seawYo6EOdR2csAOb9kSjj3zpyaSt4iPi8Y-Zw%40mail.gmail.com.

[Daniel McArdle]

No Origin Trial, just a Finch experiment. More details are coming soon! I'll be sharing a design doc for the first phase of this experiment.

The short version is that we want to measure how well the DoH ecosystem can handle new types of DNS records.

[Emily Stark]

As an FYI, we (Chrome) are currently considering defaulting all typed omnibox navigations to https://. We would fall back to http:// if https:// doesn't work, though. +Kaustubha Govind told me earlier today that HTTPSSVC is designed to not fall back if the query fails; that is, we wouldn't contact a site over http:// unless we hear affirmatively from the resolver that the domain does not have a HTTPSSVC record; is that correct?

I'm wondering, is it worth pursuing both of these projects in parallel (defaulting the omnibox to https:// and HTTPSSVC) -- or does HTTPSSVC obviate an omnibox change? I suppose that defaulting-omnibox-to-https would provide value in that:

- It will likely be implementable before HTTPSSVC can be widely deployed. (?)

- It provides some protection to users accessing sites that support HTTPS but have not configured HTTPSSVC. (Not sure how common this will be)

- It protects against attackers with different capabilities/vantage points? That is, HTTPSSVC+DoH protects against an active attacker on the client's local network, which defaulting-omnibox-to-https does not; but defaulting-the-omnibox-to-https protects against attackers on upstream non-DoH DNS hops.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAGmnN44aAM0q7W%3DXczx9qk0Jk6%2BB4ZkTP8H1Lx51ax0Mag9v9g%40mail.gmail.com.

[Eric Orth]

Is there a plan yet for how this new omnibox defaulting would work with HSTS? The story for HTTPSSVC will likely be very similar.

But in general, yes, the correct behavior will likely be to disallow HTTP fallback if Chrome has found an HTTPSSVC record.  And I agree that both efforts would provide value because I would anticipate long-term we will still have many sites without HTTPSSVC configured and many users unable to query DNS via DoH.

[Kaustubha Govind]

Eric: Just to clarify, Emily asking if we would not fall back to HTTP unless the HTTPSSVC query comes back with NXDOMAIN. For instance, could the record get dropped by an on-path attacker or the DoH server itself? What would we do if there is a SERVFAIL or timeout on the HTTPSSVC query? Is it equivalent to the A/AAAA query failing?

I do agree with the assessment that the Omnibox change provides immediate value and is worth pursuing in parallel. 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcEz2B_heRdZJq7-156idtSRhs_ROsmzNb_b30VzT8_iPQ%40mail.gmail.com.

[David Benjamin]

On Thu, Feb 13, 2020 at 8:16 PM Kaustubha Govind <kaust...@chromium.org> wrote:

Eric: Just to clarify, Emily asking if we would not fall back to HTTP unless the HTTPSSVC query comes back with NXDOMAIN. For instance, could the record get dropped by an on-path attacker or the DoH server itself? What would we do if there is a SERVFAIL or timeout on the HTTPSSVC query? Is it equivalent to the A/AAAA query failing?

The current editor's draft says that SERVFAIL and timeouts are fatal, which helps avoid downgrade attacks for some use cases. Of course, as with the rest of HTTPSSVC, we'll need experiments like this one to confirm that is viable.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAKhd1E22ZarKQnK2SR87dgbFQ916o%3DdF6fZHnqUL5077ZWsWGQ%40mail.gmail.com.

[Eric Orth]

Yes, the current non-finalized spec is that SERVFAIL or timeout for the HTTPSSVC query would be considered a complete resolve failure.  Most likely Chrome-internal implication is that, in such cases, HostResolver would return failure for the entire hostname request and refuse to give out IP addresses for the name.  So I wouldn't expect omnibox to need to worry too much about not falling back to HTTP, as the underlying stack would disallow any fallback attempts.

[David Benjamin]

In the positive HTTPSSVC case, the fallback attempt will probably be upgraded again rather than rejected per se: if the omnibox tries https, it fails, then it falls back to http, then the net stack sees either HSTS or HTTPSSVC when trying to fetch http, it'll redirect it back to https and try that again.

(If we particularly cared, we could add a toggle to URLRequest to fail rather than upgrade, taking care to clear it on redirects, but I think that behavior's fine as-is.)

[Eric Orth]

I hope we will coordinate a little better between omnibox and network service to avoid redundant/unnecessary retries/fallbacks like that, but I think that's a planning issue for another day.

[Daniel McArdle]

Hi folks, here’s a design doc describing the first phase of our HTTPSSVC experiment. We will be investigating how well the DNS ecosystem handles a new record type. For this experiment, we are inventing a new record type, dubbed the “INTEGRITY” record. Read all about it in the doc!

[Ryan Sleevi]

While you sent an early version for feedback, I did want to make sure to say thanks, as this ended up answering all of my questions for how this experiment would work, and how it could progress into a shippable implementation. Great work, and thanks for doing this.

[Yoav Weiss]

LGTM to experiment. Super excited about HTTPSSVC and its performance benefits (among others), so would be great to make sure the DoH ecosystem is built with HTTPSSVC in mind.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CACvaWvY-LGLLQC7mCWwJW_9GWOewV2SLpz6%2BzEEvTobVZhR5_Q%40mail.gmail.com.

[Joe Medley]

Daniel,

Do you have a tracking bug I can star? Also, did you mean to mark the Status entry "No active development"?

Joe

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

[Eric Orth]

Tracking bug (linked in the design doc posted above): https://crbug.com/1052476

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+u...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAJUhtG_mCQw3cWFvZs9X%2BZeOBM_v5uoDdSCO8Eh5-Gr%3DO3aQtw%40mail.gmail.com.

[Joe Medley]

Thanks! 

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

[Eric Orth]

Followup:

Chrome is now starting to experimentally query for actual DNS HTTPS records (previously known as HTTPSSVC records) on Chrome Beta channels.  We expect to start ramping up the experiment on Stable in January/February after Chrome 88 is released to Stable.

Works almost exactly the same as the INTEGRITY queries except with a different query type and response parser.  Like INTEGRITY, Chrome is just making the queries and parsing the results but not yet making any behavioral changes based on those results.  Details (mostly calling out that it's the same as the INTEGRITY queries) in the same design doc as we consider this to be just a followup step in the same overall experiment.

[Eric Orth]

[everyone but net-dev to bcc]

Another followup:

Chrome will soon begin experimenting with querying HTTPS and INTEGRITY via Classic DNS (Do53) on platforms where Chrome regularly handles Do53 via its built-in resolver (Android, ChromeOS, and MacOS).

Some minor implementation work is required to add a group policy to allow temporary enterprise opt-out in obscure cases of compatibility bugs in networks.  Mini design doc: https://docs.google.com/document/d/1RX7LsepbdTrrvfKCIH104qZyhU0jo9ZN9meTAGHufSU

I will be updating this thread with a heads up before any significant experiment rollout steps.  (Some partners and network operators that previously inquired about heads up notices for relevant experiments were pointed to watch this thread.)