Subject: [Add] avoiding unnecessary metadata in applications doing DNS / DoH

From: nusenu <[email-masked]>
Date: Thu, 11 Apr 2019 19:11:00 +0000

DNS never had something like a user-agent field and that is fine, 
but since browsers send one by default during their (non-DoH) operations
it is likely that they and other DoH clients will send the user-agent
along with their DoH queries.

This exposes unnecessary metadata to the resolver, something that
didn't exist on the resolver before DoH.

Since RFC8484 does not require user-agent headers
applications implementing DoH should not include
such metadata by default. 
Some DoH implementations do it currently but it is early
enough to improve that.

DoH Privacy Enhancement: Do not set the user-agent header for DoH requests
https://bugzilla.mozilla.org/show_bug.cgi?id=1543201

-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 11 Apr 2019 20:41:14 -0400

> such metadata by default. 

What additional entropy does User-Agent provide that is not already present in - for example - the pattern of TLS extensions or HTTP/2 settings that are sent during connection establishment?

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 11 Apr 2019 19:39:34 -0400

Moving thread from ADD to DPRIVE.

I would suggest reaching out to the authors of
https://tools.ietf.org/html/draft-dickinson-doh-dohpe-00 if you're
interested in advancing that line of work.

One major challenge related to User-Agent is forming a workable threat
model.  It seems likely that an interested server could easily identify
distinct user agents, even without this header field.  For example, the TLS
fingerprint alone is sufficient to uniquely identify most TLS
implementations[1], and different HTTP/2 implementations produce different
framing patterns.  Active probing (e.g. returning slightly invalid
responses and observing how the client reacts) would likely allow the
server to identify the client software completely.

It's harder to motivate this kind of protection if it only works against
"friendly" servers, especially because the User-Agent is extremely useful
for server operations, capacity planning, etc.

The DOHPE draft also contains several other suggestions (e.g. removing
locale and language preference information) that may be easier to justify.

[1] https://tlsfingerprint.io/

On Thu, Apr 11, 2019 at 3:12 PM nusenu <[email-masked]> wrote:

> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 11 Apr 2019 22:43:45 -0400

On Thu 2019-04-11 20:41:14 -0400, Martin Thomson wrote:
> What additional entropy does User-Agent provide that is not already
> present in - for example - the pattern of TLS extensions or HTTP/2
> settings that are sent during connection establishment?

This argument (and Ben Schwartz's) are both examples of the leaky-boat
approach to problem-not-solving.  The leaky boat approach is where you
point out to me that the boat is leaking under my seat.  I then point
out that i am not going to bother fixing the leak under me, because the
boat is also leaking under you.

If we don't reduce the entropy of (standardize) the User-Agent because
it only leaks the same entropy as TLS extensions settings, then we might
as well also not standardize TLS extensions because any standardization
effort will be moot due to the same leakage in the User-Agent.  This
beautifuly circular argument also works between UA and H2 settings, or
between H2 settings and TLS extensions themselves.

If we follow this line of reasoning, we can't possibly try to address
any of them without addressing all of them at once.  and everyone knows
that addressing all of them at once is impossible, so why bother trying?

This is a great way to decide that you will simply never fix something,
by claiming that it's impossible to do so.

But in the real world, if you want a large problem fixed, you need to
tackle individual pieces.  Solving the first individual piece might not
give you *anything* in the way of addressing your goal, but you need to
take it anyway if you want to solve the second piece, and so on.

let's not make that mistake.  Rather, let's try to fix things that we
know contribute to the concerns that people are raising, even if we
can't fix them all a once.

      --dkg

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 12 Apr 2019 12:36:27 +0100

+many to DKG below.

And in this specific situation there's an additional
reason: getting closer to systemic equivalence with
Do53 and DoT that do not have as much leakiness.

Cheers,
S.

---

From: StarBrilliant <[email-masked]>
Date: Fri, 12 Apr 2019 16:38:10 +0800

> can't fix them all a once.

Hi,

Actually this question was already discussed in the past while RFC
8484 was being proposed.

I want to give some reasons we concluded why it is a bad idea not to
suppress User-Agent.

1) User-Agent makes it possible to workaround bad implementations or
old versions. (e.g. I use User-Agent to workaround a bug in an old
version of Firefox, in my https://github.com/m13253/dns-over-https
implementation.)

2) Disabling User-Agent does not make it more private because we still
have TLS fingerprint and H/2 fingerprint. Additionally, different DNS
parsers have subtle differences which can be probed with malformed
packets or certain responses.

3) Whenever certain clients are known to have vulnerabilities, the
server warn the users to upgrade their client software by detecting
the version number in User-Agent.

Best regards,
StarBrilliant

---

From: nusenu <[email-masked]>
Date: Fri, 12 Apr 2019 22:06:00 +0000

> can't fix them all a once.

thanks for this well written reasoning.
I very much share the 'one step at a time' approach.