Intent to Experiment: Querying HTTPSSVC

464 views
Skip to first unread message

Daniel McArdle

unread,
Feb 10, 2020, 4:13:47 PMFeb 10
to net...@chromium.org

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


Jochen Eisinger

unread,
Feb 12, 2020, 8:32:06 AMFeb 12
to Daniel McArdle, net-dev, blink-dev
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

unread,
Feb 12, 2020, 9:30:45 AMFeb 12
to Jochen Eisinger, Daniel McArdle, net-dev, blink-dev
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.

PhistucK

unread,
Feb 12, 2020, 1:20:04 PMFeb 12
to Eric Orth, Jochen Eisinger, net-dev, Daniel McArdle, blink-dev
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


On Wed, Feb 12, 2020 at 8:16 PM Eric Orth <eric...@chromium.org> wrote:


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.
 

Eric Orth

unread,
Feb 12, 2020, 4:01:28 PMFeb 12
to PhistucK, net-dev, Daniel McArdle, blink-dev
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

unread,
Feb 12, 2020, 4:38:34 PMFeb 12
to Eric Orth, net-dev, Daniel McArdle, blink-dev
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

unread,
Feb 13, 2020, 12:26:30 PMFeb 13
to PhistucK, net-dev, Daniel McArdle, blink-dev
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

unread,
Feb 13, 2020, 3:42:54 PMFeb 13
to Eric Orth, PhistucK, net-dev, Daniel McArdle, blink-dev
Experimenting with HTTPSSVC seems worthwhile.

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

Daniel McArdle

unread,
Feb 13, 2020, 3:48:15 PMFeb 13
to Yoav Weiss, Eric Orth, PhistucK, net-dev, blink-dev
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

unread,
Feb 13, 2020, 6:12:13 PMFeb 13
to Daniel McArdle, Kaustubha Govind, Yoav Weiss, Eric Orth, PhistucK, net-dev, blink-dev
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.
 

Eric Orth

unread,
Feb 13, 2020, 7:04:08 PMFeb 13
to Emily Stark, Daniel McArdle, Kaustubha Govind, Yoav Weiss, PhistucK, net-dev, blink-dev
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.

David Benjamin

unread,
Feb 13, 2020, 8:51:53 PMFeb 13
to Kaustubha Govind, Eric Orth, Emily Stark, Daniel McArdle, Kaustubha Govind, Yoav Weiss, PhistucK, net-dev, blink-dev
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.
 
I do agree with the assessment that the Omnibox change provides immediate value and is worth pursuing in parallel. 



--
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.

Kaustubha Govind

unread,
Feb 14, 2020, 12:28:49 AMFeb 14
to Eric Orth, Emily Stark, Daniel McArdle, Kaustubha Govind, Yoav Weiss, PhistucK, net-dev, blink-dev
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. 

Eric Orth

unread,
Feb 14, 2020, 11:47:48 AMFeb 14
to David Benjamin, Kaustubha Govind, Emily Stark, Daniel McArdle, Kaustubha Govind, net-dev, blink-dev
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

unread,
Feb 14, 2020, 11:55:27 AMFeb 14
to Eric Orth, Kaustubha Govind, Emily Stark, Daniel McArdle, Kaustubha Govind, net-dev, blink-dev
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

unread,
Feb 14, 2020, 12:02:15 PMFeb 14
to David Benjamin, Kaustubha Govind, Emily Stark, Daniel McArdle, Kaustubha Govind, net-dev, blink-dev
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

unread,
Feb 14, 2020, 2:51:10 PMFeb 14
to Eric Orth, Ryan Sleevi, David Benjamin, Kaustubha Govind, Emily Stark, Kaustubha Govind, net-dev, blink-dev
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

unread,
Feb 14, 2020, 3:20:29 PMFeb 14
to Daniel McArdle, Eric Orth, Ryan Sleevi, David Benjamin, Kaustubha Govind, Emily Stark, Kaustubha Govind, net-dev, blink-dev
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

unread,
Feb 17, 2020, 3:00:06 AMFeb 17
to Ryan Sleevi, Daniel McArdle, Eric Orth, David Benjamin, Kaustubha Govind, Emily Stark, Kaustubha Govind, net-dev, blink-dev
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.


Reply all
Reply to author
Forward
0 new messages