Subject: [dns-privacy] Consensus and Compromise

From: Hugo Connery <[email-masked]>
Date: Thu, 13 Nov 2014 20:34:17 +0100

Hi,

1. Some mechanism for encryption between clients and recursive resolvers

Yes.  "This" should be available to all clients and, at least, optionally
provided by the resolvers.  There is a case for MUST.  A client is
a captive of their DHCP described resolver.  They may choose to not
use the network.

2.  Trust between clients (stubs) and recursive resolvers

Whether the communication to the recursive resolver is encrypted or not the
resolver itself knows all queries (data and metadata).  There is an
implicit
trust relationship  between the client and recursive resolver. 

This is a political rather than technical issue (unless some PIR style
solution is pursued) and is probably outside the scope of DPRIVE. 
Nonetheless, I would like to see it *highlighted* in whatever RFC is
produced.

3. Recursive to Authoritative

Without the possibility of encrypting this stage, the client becomes
anonymous
within the community that is using the recursive resolver.  Encrypting
this step
may be "too much" for now (and it will incur challenges for auth resolvers).

If omitted, I hope that the community will re-visit the issue.

Note that, if we only take 1. then the case of systems which implement a
local
(on system) recursive resolver receive precisely no benefit.  This
pushes towards
using available, shared, encrypted recursive resolvers which may be an
intention
and/or benefit.

I thank the IETF for considering this significant information leakage issue,
and am glad to see that a few relevant and considered solutions have emerged
for further discussion.

Regards,  Hugo Connery
--
Technical University of Denmark

---

From: Paul Wouters <[email-masked]>
Date: Thu, 13 Nov 2014 14:41:59 -0500 (EST)

> solution is pursued) and is probably outside the scope of DPRIVE.

I would like to see that any solution would actually tackle this
problem. A more and more common scenario is to only use local DNS for
bootstrap and then rely on another non-local DNS server outside the
control of the local network.

For example, if Google DNS could advertise a "resolver public key" than
I could use the hotspot DNS to pay/click ok, and then only send
encrypted DNS to Google so the local network cannot see any of it.

The same scenario would apply to ISPs whose nameservers people would
like to not trust or use.

> If omitted, I hope that the community will re-visit the issue.

Agreed. This problem is very hard because it is a DOS against
authoritative servers.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 13 Nov 2014 10:46:38 -1000

> encrypted DNS to Google so the local network cannot see any of it.

Actually, we probably want to have a mechanism for using encryption on
DHCP as well. It would be a way to close the WiFi evil twin issue.

I don't think this area actually has a bearing on choices between
proposals as we are all using TLS at the front end. The only
divergence is whether to use it on the back end or not.

So lets say we are in Panera. The coffee shop is a national chain that
wants to assure customers they are going to the real panera. They also
want to do a splash screen for T&C. Right now the mechanisms for
implementing that are folklore which is bad.

I see the following approaches:

1) Advertise a DNS name, IP address and URI in a DHCP record.

This is the simplest, the hotspot only wants to provide the data for
the very limited purpose of T&C. Making it part of DHCP allows the
platform to present the T&C dialog etc.

2) DHCP record for DPRIV DNS

This would be for a promiscuous DNS service that can be used for the
T&C transaction and then ignored thereafter. Problem with this is that
it tends to be flaky, it is not clear where the T&C bit starts and
ends.

3) Regular DHCP with upgrade in the DNS transaction.

Some EDNS option to tell the client that DPRIV is available...

Caveats:

1) Panera is not going to worry about the cost of an EV cert to
establish their WiFi service is genuine. For a small coffee shop or
non commercial WiFi this would not be an acceptable cost. Nor would
the CA service really add much to a service provider with a single
site. For the home user, getting an EV cert is definitely out of the
question.

2) Panera is doing DNS interception because they don't want people
surfing to sites showing pictures of nakid people in their cafe. Hard
to see how to reconcile this with censorship bypass because its
incompatible. The coffee shop would still have the option of filtering
on IP addresses though.

> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy