Subject: Re: [dns-privacy] Potential re-charter text

From: Brian Haberman <[email-masked]>
Date: Thu, 5 Apr 2018 15:44:29 -0400

Tim & I are still looking for feedback on this updated charter. Please
chime in or we will have to close the WG down.

Brian

On 3/21/18 9:44 AM, Brian Haberman wrote:
> Slightly updated text to capture a missing work item...
> 
> https://github.com/DPRIVE/wg-materials/blob/master/dprive-charter-2.1.txt
> 
> Regards,
> Brian
> 
> On 3/19/18 11:07 AM, Brian Haberman wrote:
>> All,
>>      The chairs have been chatting with our AD about re-chartering the
>> WG. The text below is our proposed charter that we will discuss in our
>> session this week.
>>
>> Regards,
>> Brian & Tim
>>
>>
>> DPRIVE Charter 2.0
>>
>> The DNS PRIVate Exchange (DPRIVE) Working Group develops mechanisms to
>> provide confidentiality to DNS transactions in order to address concerns
>> surrounding pervasive monitoring (RFC 7258).
>>
>> The set of DNS requests that an individual makes can provide an attacker
>> with a large amount of information about that individual.  DPRIVE aims
>> to deprive the attacker of this information (The IETF defines pervasive
>> monitoring as an attack [RFC7258]).
>>
>> The initial focus of this Working Group was the development of
>> mechanisms that provide confidentiality and authentication between DNS
>> Clients and Iterative Resolvers (published as RFCs 7858 and 8094). With
>> proposed standard solutions for the client-to-iterative resolvers
>> published, the working group turns its attention to the development of
>> documents focused on: 1) providing confidentiality to DNS transactions
>> between Iterative Resolvers and Authoritative Servers, and 2) measuring
>> the performance of the proposed solutions against pervasive monitoring.
>> Some of the results of this working group may be experimental. There are
>> numerous aspects that differ between DNS exchanges with an iterative
>> resolver and exchanges involving DNS root/authoritative servers. The
>> working group will work with DNS operators and developers (via the DNSOP
>> WG) to ensure that proposed solutions address key requirements.
>>
>> DPRIVE is chartered to work on mechanisms that add confidentiality to
>> the DNS. While it may be tempting to solve other DNS issues while adding
>> confidentiality, DPRIVE is not the working group to do this.  DPRIVE
>> will not work on any integrity-only mechanisms.  Examples of the sorts
>> of risks that DPRIVE will address can be found in [RFC 7626], and
>> include both passive wiretapping and more active attacks, such as MITM
>> attacks. DPRIVE will address risks to end-users' privacy (for example,
>> which websites an end user is accessing).
>>
>> DPRIVE Work Items:
>>
>> - Develop requirements for adding confidentiality to DNS exchanges
>> between recursive resolvers and authoritative servers (unpublished
>> document).
>>
>> - Investigate potential solutions for adding confidentiality to DNS
>> exchanges involving authoritative servers (Experimental).
>>
>> - Define, collect and publish performance data measuring effectiveness
>> of DPRIVE-published technologies against pervasive monitoring attacks.
>>
>>
>>
>> _______________________________________________
>> dns-privacy mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>
> 
> 
> 
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 5 Apr 2018 21:14:47 +0100

> chime in or we will have to close the WG down.

LGTM. Don't close it down. Get folks to do the work:-)

S

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 05 Apr 2018 16:46:54 -0400

The new charter text seems fine, even if we don't actually do all four 
work items.

--Paul Hoffman

---

From: Ian Maddison <[email-masked]>
Date: Sat, 07 Apr 2018 00:28:51 +0200

Dear DPriv

On Thu, 5 Apr 2018, at 21:44, Brian Haberman wrote:
> Tim & I are still looking for feedback on this updated charter. Please> chime in or we will have to close the WG down.

At first I was quite surprised to read this, especially in the current
climate, but on second thoughts despite all the recent press attention
regarding privacy, I don't think I've seen any mention of DNS.
I'd be extremely disappointed to see hear of the premature demise of
this WG. As we approach the fifth anniversary of the summer of Snowden,
I've the impression of a job half one, despite all the commendable
efforts of the IETF, this group, individuals like Stéphane and the
getdns team, etc, etc.
Solid stub to recursive and qnamemin standards have been established but
currently bind is the only performant DoT system and they've only
recently announced work on qname minimalisation. Privacy enabled public
recursives such as the very useful quad9.net service are still
relatively slow while the quicker ones from the good folks at Sinodun
suffer from a lack of clients, according to their published qps and
therefore can't be considered a viable solution whilst recursive to
authoritative remains unprotected.
I see a lot of effort going into outreach but it still still seems like
the general public and journalists have yet to catch on to the scale
and breadth of this DNS problem, while the engineering community may
have lost some of their initial momentum. This despite privacy becoming
a major public issue recently. So please just recharter the WG and
finish the job you started so well ! Please fix the recursive to
authoritative problem and look at alternatives to DoT, such as QUIC and
HTTPS before you go.
Many thanks :o)

Ian Maddison

---

From: Benno Overeinder <[email-masked]>
Date: Sat, 7 Apr 2018 01:35:44 +0200

Hi,

Not necessarily reacting on the re-charter text discussion, but trying
to clear-out some potential misunderstanding (with me maybe?).

On 04/07/2018 12:28 AM, Ian Maddison wrote:
> recently announced work on qname minimalisation. 

For information to the WG, Unbound and Knot Resolver have implemented
DNS-over-TLS for one or two years now, and both are in use.  Also qname
minimalisation has been implemented in Unbound and Knot Resolver for 2
years already, and the feature is used by operators.

An other DNS-over-TLS solution is PowerDNS recursor in combination with
dnsdist; and in a similar way, BIND setups are a combination with NGINX
or HAProxy.

All solutions above are stable performant DNS-over-TLS implementations.
The open-source developers of all DNS resolvers mentioned above are
actively engaged and work closely together to secure interoperability.

> the general public and journalists have yet to catch on to the scale and
> breadth of this DNS problem, while the engineering community may have
> lost some of their initial momentum.

Only speaking for the open-source DNS implementers, this is certainly
not the case.  We all invest substantial time in the continued
development of DNS privacy features/functionality in our software.

Best regards,

-- Benno

-- 
Benno J. Overeinder
NLnet Labs
http://www.nlnetlabs.nl/

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 6 Apr 2018 17:33:22 -0700

> On Apr 6, 2018, at 3:28 PM, Ian Maddison <[email-masked]> wrote:
> I'd be extremely disappointed to see hear of the premature demise of this WG.
> As we approach the fifth anniversary of the summer of Snowden, I've the impression
> of a job half one, despite all the commendable efforts of the IETF, this group,
> individuals like Stéphane and the getdns team, etc, etc.

Agreed.

> Privacy enabled public recursives such as the very useful quad9.net service are still relatively slow while the quicker ones from the good folks at Sinodun suffer from a lack of clients

I take it the comparison you’re drawing is to the ones that John and Sara are running at 145.100.185.15/16?  If so, I’m not sure it’s useful to compare two servers in one location to 800 servers in 180 locations, but if you’re seeing poor performance from any Quad9 node, please open a bug report with a traceroute, so one of our folks can see what’s wrong and get it fixed.

> I see a lot of effort going into outreach but it still still seems like the general public and journalists have yet to catch on to the scale and breadth of this DNS problem

Agreed.

                                -Bill

---

From: Ian Maddison <[email-masked]>
Date: Sat, 07 Apr 2018 08:05:15 +0200

Hi Benno,

On Sat, 7 Apr 2018, at 01:35, Benno Overeinder wrote:
> For information to the WG, Unbound and Knot Resolver have implemented> DNS-over-TLS for one or two years now, and both are in use.
> Also qname> minimalisation has been implemented in Unbound and Knot Resolver for 2> years already, and the feature is used by operators.
> 
> An other DNS-over-TLS solution is PowerDNS recursor in
> combination with> dnsdist; and in a similar way, BIND setups are a combination
> with NGINX> or HAProxy.
> 
> All solutions above are stable performant DNS-over-TLS
> implementations.> The open-source developers of all DNS resolvers mentioned above are
Do they support rfc7828 EDNS0 keepalive and provide out of order
responses ?

---

From: Benno Overeinder <[email-masked]>
Date: Sat, 7 Apr 2018 11:21:50 +0200

Hi Ian,

> On 7 Apr 2018, at 08:05, Ian Maddison <[email-masked]> wrote:
> 
> Hi Benno,
> 
> Do they support rfc7828 EDNS0 keepalive and provide out of order responses ?
> 

Fair point.  

In the server implementation table https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Implementation+Status the ticks with RFC7828 EDNS0 keep alive and OOP in the “context” of TCP/TLS features are currently BIND only. 

But to put things in perspective, we have now a colourful bag of caching resolvers/forwarders, with or without reverse proxies (e.g., NGINX, HAProxy or dnsdist) that can be used in various setups to run a DNS-over-TLS service.  I very much appreciate your operational perspective on the DNS-over-TLS implementations, either providing them to customers (running the servers) or how you would like to see these services made available (from a client perspective).  I hope to continue this discussion with you and other network engineers/operators.

To end in a positive swing, there is a lot of energy with the open-source DNS software developers and we are close to put the final ticks in the implementation table.  Unbound will do so in one of the next releases, Knot resolver made good progress in the past period, BIND developers are implementing DNS-over-TLS natively, and the PowerDNS developers support DNS-over-TLS in their product range.

Cheers,

— Benno

-- 
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/

---

From: Erik Kline <[email-masked]>
Date: Mon, 9 Apr 2018 01:43:04 -0700

Charter 2.1 looks fine to me.

---

From: Tony Finch <[email-masked]>
Date: Mon, 9 Apr 2018 14:41:57 +0100

> All solutions above are stable performant DNS-over-TLS implementations.

I think what Ian is referring to is support for concurrent queries and
out-of-order responses.

I briefly tested a few resolvers starting from an empty cache, making 2000
queries with a max concurrency of 100 outstanding queries. I'm using
`adns` which pipelines queries down one persistent TCP connection.

With BIND 9.11 (concurrent TCP queries) it took 42s over UDP and 42s over
TCP.

With BIND 9.10 (serialized TCP queries) it took 72s over UDP and over TCP
it took 427s - plus I had to reduce the TCP concurrency to 10 to stop the
client timing out, and even with this limited concurrency, a couple of
slow queries can cause several following queries to time out even if they
would otherwise have succeeded.

With Unbound over UDP this test completed in 110 seconds, but over TCP it
took 870 seconds, and again I had to restrict the concurrency to reduce
timeouts.

There's a lot of variation in the times because most of the delay is due
to broken authoritative servers (the 2000 queries come from a very crappy
dataset) and Unbound and BIND have different strategies for handling
brokenness.

Unlike my test, for DNS-over-TLS the delay we usually care about is the
stub/resolver latency (because much of the use case involves talking to
resolvers that are further away). It's important that the stub doesn't
have artificial concurrency limitations so it can compensate for this
latency without having to work around head-of-line blocking. It's also
important that the stub can use a persistent connection so it isn't paying
for the multi-round-trip setup cost on every query.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Cyclonic gale 7 to severe gale 9, occasionally storm 10 for a time
in northwest, becoming northwesterly 5 to 7 later. Very rough or high,
occasionally very high for a time in west, becoming rough or very rough later.
Rain or showers. Good, occasionally poor.

---

From: Tony Finch <[email-masked]>
Date: Mon, 9 Apr 2018 15:26:42 +0100

Let's retry the tests with a hot cache, since that's maybe a bit more
fair. I've picked the shortest times I could get, which involved heating
up the resolver until it was no longer waiting 10s or 30s on lame
authoritative servers.

Unbound 1.6.0 TCP 8s
Unbound 1.6.0 UDP 0.4s
BIND 9.11 TCP 0.5s
BIND 9.11 UDP 0.5s
BIND 9.10 TCP 3s
BIND 9.10 UDP 0.5s
1.1.1.1 TCP 0.5s
1.1.1.1 UDP 0.4s
8.8.8.8 TCP 5s # drops connection after 60 queries
8.8.8.8 UDP 220s # it hates me
9.9.9.9 TCP 1s
9.9.9.9 UDP 3s
64.6.64.6 TCP 0.5s
64.6.64.6 UDP 0.5s

Tony.

---

From: Brian Haberman <[email-masked]>
Date: Tue, 10 Apr 2018 11:30:58 -0400

All,
     Thanks for the feedback. Tim and I will add some milestones to the
proposed charter and get it to our illustrious AD for review/handling.

Regards,
Brian