Subject: [dns-privacy] What is the starting point for config?

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Mar 2015 13:36:17 -0400

On Fri, Mar 20, 2015 at 1:01 PM, Paul Wouters <[email-masked]> wrote:
> On Fri, 20 Mar 2015, Watson Ladd wrote:

> If the starting point is "preconfigured public key", I see no reason why
> not to use IPsec or TLS as the transport to encrypt regular DNS traffic.

Good point.

What is the starting point that we want for configuration of PrivateDNS?

Today the user has to enter raw IP addresses or rely on the DHCP
parameters. Neither is going to be acceptable as a full solution.

My preference for what the user enters is a DNS name. I would then use
the DHCP DNS parameters to bootstrap the system.

Remember that Private DNS is likely to be introduced via application
libraries before it becomes a platform feature. So any scheme that
relies on DHCP parameters being visible is going to commit a layer
violation.

I think that all the proposals currently on the table propose the use
of a DNS name as the preferred method of service identification. The
difference comes in how that identification is used. The options being

1) Make use of TLS for both establishing the service connection and
the presentation framing.

2) Make use of TLS to establish a service connection and then use a
new presentation framing.

3) Use DNS records to establish the service connection and then use a
new presentation framing.

I began with approach (1) and eventually rejected it in favor of (1+2)
because this is the only way to meet the performance and reliability
criteria.

Approach 3 certainly meets the performance criteria. I am very
doubtful about its ability to meet the necessary connection criteria.
For DNS Privacy to be acceptable to end users it must work 100% of the
time with no iffs or buts. The only exception being the case where a
MITM attacker is intentionally filtering DNS Privacy traffic.

I can't see how any proposal that requires new RRs is going to meet
that 100% requirement. 97% is not good enough, nor is 99%. The first
time a security measure stops someone doing work it is disabled and
once that happens it will never be turned back on again.