Subject: Re: [dns-privacy] User Perspective

From: Brian Haberman <[email-masked]>
Date: Mon, 24 Sep 2018 10:08:41 -0400

All,
     I would like the focus for this week (9/24-9/30) to be on
clarifying the requirements from the user's perspective. So far, I have
seen:

* DNS transaction privacy, if possible
* User willingness to send PII if transaction is encrypted

Do others have additional requirements?

If you agree with the above, could you describe a scenario to highlight
the requirements?

Regards,
Brian

On 7/19/18 2:23 PM, Brian Haberman wrote:
> This thread is for discussion of the user perspective of DNS privacy
> between the recursive resolver and authoritative servers.
> 
>     - Focus on *what* is needed.
>     - Avoid *how* to achieve it.
>     - Consider both ends of DNS the exchange.
>     - Scenarios will frame the discussion.
> 
> 
> 
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Amelia Andersdotter <[email-masked]>
Date: Mon, 24 Sep 2018 19:58:26 +0200

> Do others have additional requirements?

I propose to add:

* Data management practises (i.e. profiling, advertisement, re-selling, etc)

> If you agree with the above, could you describe a scenario to highlight

I have difficulties seeing how a user (within the meaning of individual
internet consumer) has any practical choice to other than to share PII
with a DNS provider? It's not so much about "willingness" as it is about
"feeling comfortable with".

best regards,

Amelia

-- 
Amelia Andersdotter
Technical Consultant, Digital Programme

ARTICLE19
www.article19.org

PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55

---

From: Melinda Shore <[email-masked]>
Date: Mon, 24 Sep 2018 12:14:20 -0600

> "feeling comfortable with".

I think it might be helpful to scope the data under discussion
and identify what counts as PII under the context of the DNS.

This may be outside the scope of the current discussion but I've
been somewhat concerned lately by some of the assertions being
made about who to trust (the "who" in this case being recursives)
in privacy-protected DNS transactions.  The assertions tend to be
fairly global but it seems to me that in at least some cases
(for example, secure messaging) the application will have some
fairly specific requirements around privacy that it's unwilling to
leave to the default OS configuration, the browser, the service
provider, etc.

Melinda

---

From: Tony Finch <[email-masked]>
Date: Tue, 25 Sep 2018 10:32:05 +0100

Amelia Andersdotter <[email-masked]> wrote:
> with a DNS provider?

Yes, me too.

Since the overall topic is recursive -> authoritative, the questions imply
some mechanism for the user to communicate their privacy policy to the
recursive server, or perhaps it would be more useful for clients to ask
the recursive server what its policies or capabilities are. But what
happens when there is a mismatch?

Specific information leaks that we might care about:

* QNAME minimization or not?

* EDNS client subnet or not?

* Upstream encryption available or not? (asking for it to be required is a
  "break the Internet" switch so it doesn't make sense)

And the points Amelia made about data management which I might recast more
mechanically as:

* Passive DNS logging on the upstream side?

* Query logging on the client side?

Some of this is stuff that a recursive server knows about itself, and
could (reasonably easily) communicate to a client; some of it is about the
deployment and setup around the server which it doesn't necessarily know
(and I don't think it would be realistic to expect operators to configure
their servers to say they are running packet captures on DNS traffic...)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Dogger, Fisher, German Bight, Humber: West or northwest 4 backing southwest 5
to 7, occasionally gale 8 later except in Humber. Slight or moderate becoming
moderate or rough, then very rough later in Fisher. Showers. Good.

---

From: Martin Hoffmann <[email-masked]>
Date: Tue, 25 Sep 2018 12:08:28 +0200

>> internet consumer) has any practical choice to other than to share PII

There’s always the option to run your own recursive, possibly even
on your own machine. In the latter case, it even becomes a
practical option for non-technical users.

In this case, the discussion about privacy between recursive and
authoritative becomes much more important since it becomes easier
to link the information leaked to the authoritative to a specific
user (well, device). But then, how much information do you leak,
really, to a individual authoritative?

I’ve been meaning to do a proper privacy analysis of the possible
option for a user’s DNS setup. Which of these leaks the least
amount of information and, as a result, is there any measures that
can be taken to leak even less? I have a sense that the gut
feeling assessments that people often do (“Just run your own
Unbound on a private server”) may not actually hold up.

Not sure if such an analysis is relevant for this particular
work, but it may still be useful to do as part of this working
group.

> happens when there is a mismatch?

I’m not sure such capability announcement is useful. It can help with
making a decision when automatically picking a recursive -- but then
you can’t actually put too much trust in it because it easy to claim
whatever and, since automation hides the decision, hardly anyone
will ever check.

Essentially, you will have to make a trust decision for a particular
recursive service. There may be technical means to support this, but
these need to be off path and operated by independent third parties.

Kind regards,
Martin

---

From: Lanlan Pan <[email-masked]>
Date: Tue, 25 Sep 2018 12:53:54 -0400

clients hide on proxy,  but still get the specified network topological
close response.

-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 25 Sep 2018 22:43:44 +0530

>     - Scenarios will frame the discussion.

I live in a part of the world where RTT to other parts of the world
widely varies. Average RTT to "the west" or "the east" is quite high.

These days many zones are concentrated on anycast "local" namesevers,
but a lot of nameservers are not local too. Many users don't use "cloud"
resolvers either - they use resolvers on their LAN.

DNS is at the head of any user-initiated internet connection and the
turnaround time of a DNS request is definitely influenced by the
resolution time at the head of the sequence of steps. Recursive
resolution involves several RTTs already and any extra client->server
roundtrips will be a multiplier overall.

I want recursive resolution to work efficiently, for everyone, for every
type of scenario. This is what is needed.

During the "how-to-achieve-it" phase, attention should be given to not
adding extra roundtrips (to keep it as close as possible to the RFC 1035
UDP scenario). Various new facilities such as TCP's fast open, TLS false
start, etc. should not be taken for granted - considerion should be
given to the average and worst case scenarios, esp. queries in unseen
zones to non-anycast-"cloud" nameservers that aren't "known".

As an example, consider yourself as a person who has the resolver on the
LAN and is a reddit.com or news.ycombinator.com visitor. You visit these
websites and open links to various random websites. You don't want to be
stuck at "Looking up example.com.." for seconds longer for each new
query (which miss cache as they are new usually unvisited websites)
compared to the RFC 1035 UDP case. The internet would suck then.

		Mukund

---

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 25 Sep 2018 22:51:32 +0530

On Tue, Sep 25, 2018 at 10:43:44PM +0530, Mukund Sivaraman wrote:
> resolution time at the head of the sequence of steps.

That should say "turnaround time of the entire user-initiated internet
action", not just DNS request.

		Mukund

---

From: Tony Finch <[email-masked]>
Date: Tue, 25 Sep 2018 20:15:09 +0100

> zones to non-anycast-"cloud" nameservers that aren't "known".

Yes, I very much agree.

As I understand it, TLS false start is able to reduce the 2RTT TLS/1.2
handshake to 1.5RTT (same as a session resume). For TLS/1.3 cold starts
and session resume are the same 1.5RTT, and sessions can also be resumed
with 0RTT which is very yummy for the DNS. So if I'm allowed to assume
TLS/1.3 then false start doesn't buy us anything.

The cold start time for DoT is 3RTT.

For DNS-over-QUIC I think that could drop to 2RTT, or maybe 1RTT? I don't
know QUIC's handshake.

The warm start time should soon be 0RTT.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
champion the freedom, dignity, and well-being of individuals

---

From: Christian Huitema <[email-masked]>
Date: Tue, 25 Sep 2018 13:40:59 -0700

> The warm start time should soon be 0RTT.

The basic QUIC handshake will be 1-RTT before sending the first query,
with two exceptions:

1) The server may require a token exchange (similar to SYN cookies or
DNS cookies) to protect against DOS attacks, in which case the handshake
will take 2 RTT.

2) If the client has established a connection previously and obtained a
"resume token", it could use 0-RTT, and send the first query immediately
after the initial QUIC packet -- in fact in the same UDP packet as the
initial QUIC packet.

Using 0-RTT is a trade-off between security and performance, because
0-RTT packets can be subject to replay attacks. That's true for 0-RTT in
QUIC and also 0-RTT in TLS. If you are really concerned about privacy,
the prudent decision is to not use 0-RTT.

I ran a number of simulations comparing DNS over QUIC to DNS over UDP or
TCP, considering QUIC with and without 0RTT. The high level summary is
that for traffic from client to recursive, there is very little difference:

* TCP and QUIC-1RTT suffer a 1RTT penalty when a new connection is
required, but observations of traffic show that this is a relatively
rare event between client and recursive.
* TCP and QUIC benefit from better re-transmission handling than UDP;
they can use "dup ACK" or "selective ACK" processing, when UDP has to
rely on timers only.
* When re-transmissions are necessary, TCP suffers from "head of line
blocking". UDP and QUIC do not.
* QUIC and TCP can carry long messages. UDP has to rely either the TC
bit and TCP fall back.

I did not model TLS. My assumption is that TLS will be mostly equivalent
to TCP, but requires an extra round trip to set up the connection unless
you can use TCP fast open.

The high level summary is that if there is some truncation and fallback
happening, UDP performs less well than either TCP or QUIC. If 0-RTT is
enabled, QUIC performs better than either UDP or TCP in all scenarios;
if it is not, QUIC still performs slightly better than TCP or TLS,
because it does not suffer from head of line blocking.

-- Christian Huitema

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 26 Sep 2018 03:00:15 +0530

Hi Christian

> that for traffic from client to recursive, there is very little difference:

I'm not familiar with the QUIC protocol, but following what you're
saying:

QUIC handshake + query = 2 roundtrips

If there's a "connection" previously, query = 1 roundtrip

RFC 1035 UDP query = 1 roundtrip

RFC 1035 TCP query = 1 roundtrip if connection exists, 2 for syn,ack+query

The 0 roundtrip case occurs only when there are no fetches involved
(e.g., when the answer is found in cache, but there are other cases).

So there will be a difference (at least double RTT latency vs. DNS over
UDP) when the query requires talking to a new nameserver. Some desired
security features such as DHE for forward secrecy may need additional
round trips, so pros and cons of what is picked will need discussion.
It looks like the parent of this thread wants to gather usage stories
only and does not want us to discuss implementation details, so let's
continue this discussion at another time when the requirements are
gathered.

		Mukund

---

From: Tony Finch <[email-masked]>
Date: Wed, 26 Sep 2018 12:15:59 +0100

> The basic QUIC handshake will be 1-RTT before sending the first query,

Thanks for those details!

> the prudent decision is to not use 0-RTT.

Correct me if I'm wrong, but my understanding is that the 0RTT replay
attack is not a privacy problem, but is a problem if the payload has
undesirable side-effects. The 0RTT privacy problem is the same as for TLS
session resumption: the session details can be used to track clients.

For privacy-conscious clients, I think it makes sense to use session
resumption for the lifetime of a particular layer 2/3 network connection,
and drop session tokens when roaming to a different connection. So you
benefit from the improved performance while the server has other ways to
track you, but it's harder for the server to track clients from place to
place.

(this is more of a stub -> recursive concern rather than recursive ->
authoritative)

> If 0-RTT is enabled, QUIC performs better than either UDP or TCP in all
> scenarios; if it is not, QUIC still performs slightly better than TCP or
> TLS, because it does not suffer from head of line blocking.

QUIC is something nice to look forward to :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Bailey: West 5 to 7, decreasing 4 for a time. Very rough, becoming rough. Rain
then showers. Good occasionally poor.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 26 Sep 2018 08:26:37 -0700

> session resumption: the session details can be used to track clients.

An attacker could replay the 0-RTT packet, and observe whether it
creates a particular side effect at the server end. For example, replay
the traffic from client to recursive, and observe whether the resolver
issues a query to particular DNS server. I think DKG did the analysis in
details. He should probably elaborate.

> (this is more of a stub -> recursive concern rather than recursive ->

There is indeed that other issue with 0-RTT and session resumption. It
provides the server with a tracking cookie.

> QUIC is something nice to look forward to :-)

Yes...

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Wed, 26 Sep 2018 08:36:17 -0700

> continue this discussion at another time when the requirements are
The QUIC connection provides DHE and forward secrecy by default, just
like TLS 1.3. This is already accounted for in the "1 roundtrip". Note
that there are really 4 sources of latency:

* Initial connection setup -- UDP or QUIC+0RTT beat TCP, TLS and QUIC
without 0-RTT by 1 RTT
* Inefficient retransmission -- in case of errors, corrections may
arrive much later with UDP
* Head of queue blocking -- an issue for TCP and TLS, not for UDP or
QUIC, may cause 1 RTT delay of packets coming after and error
* Fallback to TCP -- an issue with UDP if the response does not fit in a
single packet.

When you are comparing protocols, you need to consider all 4 issues, not
just the initial connection setup. Estimate probabilities of issues
based on traffic patterns, see what happens. For example, in the
resolver to authoritative scenario, you are likely to use DNSSEC, in
which case UDP suffers from the fallback to TCP a lot.

-- Christian Huitema

---

From: Tony Finch <[email-masked]>
Date: Wed, 26 Sep 2018 16:49:09 +0100

Christian Huitema <[email-masked]> wrote:
> issues a query to particular DNS server.

Ah, yes, if you can see the upstream queries, even when encrypted they are
quite a lot more leaky than the cache side channel.

I'm now imagining a resolver that sends steganographic chaff queries when
there's a cache miss :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
people involved in running their communities