Subject: [dns-privacy] New draft on encrypting the stub-to-resolver link: draft-hoffman-dns-tls-stub-00.txt

From: Paul Hoffman <[email-masked]>
Date: Mon, 18 Aug 2014 10:59:22 -0700

Greetings. I created a new proposal on a simple way to do DNS over TLS between stubs and resolvers. Comments are appreciated.

--Paul Hoffman

> A new version of I-D, draft-hoffman-dns-tls-stub-00.txt
> has been successfully submitted by Paul Hoffman and posted to the
> IETF repository.
> 
> Name:		draft-hoffman-dns-tls-stub
> Revision:	00
> Title:		Using TLS for Privacy Between DNS Stub and Recursive Resolvers
> Document date:	2014-08-18
> Group:		Individual Submission
> Pages:		6
> URL:            http://www.ietf.org/internet-drafts/draft-hoffman-dns-tls-stub-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-hoffman-dns-tls-stub/
> Htmlized:       http://tools.ietf.org/html/draft-hoffman-dns-tls-stub-00
> 
> 
> Abstract:
>   DNS queries and responses can contain information that reveals
>   important information about the person who caused the queries, and it
>   would be better if eavesdroppers were unable to see DNS traffic.
>   This document describes how to use TLS for encrypting DNS traffic
>   between a system acting as a DNS stub resolver and a system acting as
>   a DNS recursive resolver.

---

From: Hosnieh Rafiee <[email-masked]>
Date: Tue, 19 Aug 2014 13:56:11 +0000

Hi Paul,

> Greetings. I created a new proposal on a simple way to do DNS over TLS
> between stubs and resolvers. Comments are appreciated.
> 

I read your draft and have some questions as followings:

Section 2. "If the recursive resolver
   responds on port 443, both the client and the server MUST use the
   ALPN [RFC7301] extension to TLS, and MUST use "dns" as the
   identification sequence in ALPN."

Still the nodes are in processing the hello client exchange and the encryption was not happened. As you explained in your draft, opportunistic security is in use. In other words, the server might not have certificate that is signed by a CA.  In this case how the client or server react when an attacker intercept this communication and change "dns" to something else?  
IMHO, there is a missing explanation of the case where this ALPN changes.
You explained in "security consideration" section that ALPN is only for applications to identify this protocol and normally by port numbers this protocol would be verified but I guess you have used one of popular port for TLS. Now the question is that if an attacker has an opportunity to change this ALPN, what will happen?
How your client or server detects that this supposed to be used as resolver authentication?

I think there is something important missing in your draft. For resolver's scenario IMHO, there is two important cases that the first one has a prioriry over the second one (this is of course my opinion and might not be the same as others)
1- authentication

2- encryption 

I think authentication for a resolver is essential and more important than encryption. Because if this authentication cannot be happened then the whole next security steps will fail. 
if you cannot always authenticate a resolver because it does not always carry a valid certificate, the data receives from this resolver is not trusted so IMHO, opportunistic security is not helpful otherwise you have a method to verify your resolver.  
I agree that opportunistic security would be helpful in some scenarios such as sending an email to somewhere. Because sending plain text data allow the exposal of the content of email. But IMHO, in scenarios where authentication has priority than encryption, opportunistic security is similar to not having any security. In other words, exposal of domain names are not as important as verification of the resolver.

IMHO, opportunistic security is useful for cases where once the attacker might have an opportunity to retreive data from a user (it only impact on once communcation) But it is not helpful when it might impact the whole next communications. This is true for resolver because all the next communication will be influenced by this first riski step.

Sorry for my long email,
Best,
Hosnieh

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Aug 2014 10:41:00 -0400 (EDT)

> Still the nodes are in processing the hello client exchange and the encryption was not happened. As you explained in your draft, opportunistic security is in use. In other words, the server might n…

encryption might happen without authentication.

> Now the question is that if an attacker has an opportunity to change this ALPN, what will happen?

encryption without authentication is not enough to defend against active
attacks. If possible, use authenticated encryption.

Note that DNSSEC provides authenticity of DNS data. So the only part of
authentication that you gain is about privacy (encryption) of data, not
about data integrity.

> I think there is something important missing in your draft. For resolver's scenario IMHO, there is two important cases that the first one has a prioriry over the second one (this is of course my op…

If I'm at starbucks, I care more about encrypting the last mile then
authenticating the random starbucks location. And even if I
authenticated the starbucks, they will just use an ISP DNS server
that sees all the queries, so that local authentication does not
really help you much anyway.

> I think authentication for a resolver is essential and more important than encryption.

DNSSEC allows us to ask DNS data from random attackers, as we will be
able to verify the authenticity of data. I do not need to authenticate
the resolver for that.

So this is all about encryption. We might want to authenticate with the
network to encrypt with the good guy and not the bad guy. But if you're
in a random untrusted network, you are going with an unknown guy anyway,
so authentication matters much less.

Of course, if you can just level the network and setup a secure
authenticated and encrypted DNS layer up to a trusted party, like
your own DNS server via VPN, google dns or opendns via this draft's
method plus an out-of-band public key for authentication, all the
better. But these are two very distinct cases.

> But IMHO, in scenarios where authentication has priority than encryption, opportunistic security is similar to not having any security. In other words, exposal of domain names are not as important as verification of the resolver.

This draft says nothing about authenticity of DNS data. For that, there
is DNSSEC.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 Aug 2014 07:48:48 -0700

> Still the nodes are in processing the hello client exchange and the encryption was not happened. As you explained in your draft, opportunistic security is in use. In other words, the server might n…

I'm not sure how to interpret your question. If there is an MITM who wants to watch the DNS traffic, why would they change the ALPN name to prevent DNS from passing?

> IMHO, there is a missing explanation of the case where this ALPN changes.

I can add that if I understood what it might change to.

> You explained in "security consideration" section that ALPN is only for applications to identify this protocol and normally by port numbers this protocol would be verified

????? The security considerations say nothing about ALPN.

> but I guess you have used one of popular port for TLS. Now the question is that if an attacker has an opportunity to change this ALPN, what will happen?

If both sides are not using ALPN of "dns", then communication doesn't happen. Is that not clear from RFC 7301?

> I think authentication for a resolver is essential and more important than encryption. Because if this authentication cannot be happened then the whole next security steps will fail. 

Great! Use the policy knob explicitly listed in section 2.1.

> IMHO, opportunistic security is useful for cases where once the attacker might have an opportunity to retreive data from a user (it only impact on once communcation) But it is not helpful when it m…

It is not the length that bothers me: it is the attitude of "because I have this policy for my own traffic, the rest of you cannot have better privacy because I don't want the protocol to allow it".

--Paul Hoffman

---

From: Hosnieh Rafiee <[email-masked]>
Date: Tue, 19 Aug 2014 15:09:51 +0000

> 
> > Still the nodes are in processing the hello client exchange and the
> encryption was not happened. As you explained in your draft,
> opportunistic security is in use. In other words, the server might not
> have certificate that is signed by a CA.  In this case how the client
> or server react when an attacker intercept this communication and
> change "dns" to something else?
> 

But this fails... Because of the reason that I explained in my last message...Because your connection can be directly to the attacker's resolver and then you redirected to his own places or all the other communication would be through that attacker. So , the question is now does it matter that whether you encrypt this communication since you already have a MITM in your communication? Is it really important now?
IMHO , NO...
This is why I said it is different than sending an email because if your email goes through third parties only that third party have access to that certain message but not all the data exchanged after that with that certain server. The likelihood is not high. But when we are talking about a resolver, all your next communication will be influenced by this attacker because whatever place you go, it doesn't matter that you encrypt this data but it is through this attacker.

> encryption without authentication is not enough to defend against
> active attacks. If possible, use authenticated encryption.
> 

Data integrity is different than authentication. I am not talking about data integrity. If you can verify the data integrity of a node, it doesn't mean that it is authenticated. DNSSEC, at the moment is unable at the moment to protect his last mile and your draft is supposed to provide this protection but at the moment it does not.

> > I think there is something important missing in your draft. For
> > resolver's scenario IMHO, there is two important cases that the first
> > one has a prioriry over the second one (this is of course my opinion
> > and might not be the same as others)
> > 1- authentication
> >
> > 2- encryption
> 
> authenticated the starbucks, they will just use an ISP DNS server that
> sees all the queries, so that local authentication does not really help
> you much anyway.

Doesn't make sense... Your data is now all go through attacker, it doesn't matter for you? Then what privacy is supposed to be provided to the user?

> able to verify the authenticity of data. I do not need to authenticate

This is wrong. Then why do you bother yourself to encrypt the resolver. When you do not authenticate your resolver, what is important that some people do not see what you are browsing? 

I disagree with you and I think authentication and encryption together make sense. Even authentication alone is securer than encryption alone. 

> so authentication matters much less.

The question is what you are encrypting? Some domain names? Are they as important as you really need to do so? 
It is not the question of untrusted network, it is about pervasive monitoring. The good guy can be a network administrator or a government?!! who also interested to receive information passed through this network. He can easily play MITM attack since you trust this resolver in any case. 

When you cannot authenticate a node, any node in even a good network can play this MITM attack. One example, you want to hide what you are browsing from your colleague... well, that is easy, your colleague will introduce his computer as a resolver and play MITM attack. Then who are you hiding the domain name or whatever stored in DNS resolver from?

> authenticated and encrypted DNS layer up to a trusted party, like your
> own DNS server via VPN, google dns or opendns via this draft's method
> plus an out-of-band public key for authentication, all the better. But
> these are two very distinct cases.

This is quite different. IMHO both authentication and encryption are the requirements for resolver privacy. 

> > But IMHO, in scenarios where authentication has priority than
> encryption, opportunistic security is similar to not having any
> security. In other words, exposal of domain names are not as important
> as verification of the resolver.
> 

DNSSEC cannot do anything when your node doesn't know who is it connecting to... when you cannot verify the source of your message, data authenticity and encryption is not really useful. In any case, DNSSEC cannot help you in this scenario.

Best,
Hosnieh

---

From: Joe Abley <[email-masked]>
Date: Tue, 19 Aug 2014 11:28:30 -0400

> authentication that you gain is about privacy (encryption) of data, not

Just a small word of caution, here: the gap between DNSSEC does and DNSSEC can is deployment, and deployment to date has been modest.

[With a handful of glorious exceptions, TLDs that have made DNSSEC available to date have struggled to get more than a handful of registrants to do anything with it. With a similarly-glorious handful of exceptions, registrars who have the ability to ship DS/DNSKEY data upstream for their customers have declined to let their customers do so. Most resolvers don't have a trust anchor robustly installed, or are not configured for or cable of validation in any case. Things are getting better; this is intended to be realism, not pessimism.]

When we say "we don't have to worry about X because DNSSEC" we are in some sense making our proposals operationally dependent on widespread DNSSEC deployment.

Perhaps this is not always a bad idea, since DNSSEC needs more reasons for people to deploy it; on the other hand, in some cases perhaps it *is* a bad idea, since gating deployment of your own protocol on something that is struggling seems like a losing proposition unless you're quietly placing side bets the other way and intend to throw the race.

It's possible to detach DNSSEC deployment from privacy. We think we are doing that in dns-onion. (Granted, that proposal does not even attempt to address privacy between stub and resolver.)

Just a thought.

Joe

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Aug 2014 12:11:04 -0400 (EDT)

> Data integrity is different than authentication. I am not talking about data integrity. If you can verify the data integrity of a node, it doesn't mean that it is authenticated. DNSSEC, at the mome…

That's not how I read the draft. The last mile protection needed is
privacy, not integrity. I believe every node on the planet needs to
validate or have a trusted path to a validator. But that's all unrelated
to this draft. This drafts is about encrypting (and maybe possible
authenticating) the last mile. Protection against passive attackers,
(and maybe protection against active attackers)

> Doesn't make sense... Your data is now all go through attacker, it doesn't matter for you? Then what privacy is supposed to be provided to the user?

Most attackers at the starbucks can only monitor what I send and receive,
and do not actively send attacking packets to me.

> This is wrong. Then why do you bother yourself to encrypt the resolver.

To prevent wifi monitors from reading my DNS queries and answers.

> When you do not authenticate your resolver, what is important that some people do not see what you are browsing?

That's my call to make, not yours.

> I disagree with you and I think authentication and encryption together make sense. Even authentication alone is securer than encryption alone.

I have authentication of data via DNSSEC already. And I did not say it
makes no sense to authenticate the local resolver. If you can, great and
do it (and the draft says do it via some out-of-band method). But how on
earth am I going to authenticate joe random coffeeshop from joe random
attacker???

> The question is what you are encrypting? Some domain names? Are they as important as you really need to do so?

Again, that is my call to make, not yours. There is a difference between
the network owner/manager and the dozens of guests on the network. I
trust one more than the other.

> It is not the question of untrusted network, it is about pervasive monitoring. The good guy can be a network administrator or a government?!! who also interested to receive information passed throu…

And so can they when you authenticate the starbucks wifi, who then does
a backhaul to their DSL provider's DNS server. So I fail to see what
authentication of the local DNS server with authenticated encryption
on the local wifi, helps me from nation state monitoring? That's not
really what this draft is trying to do. If you need that, you need the
tor network for DNS as a starting point....

> When you cannot authenticate a node, any node in even a good network can play this MITM attack. One example, you want to hide what you are browsing from your colleague... well, that is easy, your c…

Yes, you made this point a few times now. And I answered with explaining
passive versus active attacks.

> IMHO both authentication and encryption are the requirements for resolver privacy.

As I explained, authentication of joe random resolver is pretty
pointless. I'm at the mercy of the DHCP server, for which there is
no authentication whatsoever anyway.

> DNSSEC cannot do anything when your node doesn't know who is it connecting to... when you cannot verify the source of your message, data authenticity and encryption is not really useful. In any cas…

DNSSEC allows me to use unknown or untrusted resolvers. While I am not
sure of my privacy, I'm pretty sure about my data integrity.

Paul

---

From: Hosnieh Rafiee <[email-masked]>
Date: Tue, 19 Aug 2014 16:55:11 +0000

Paul,

> 
> > Data integrity is different than authentication. I am not talking
> about data integrity. If you can verify the data integrity of a node,
> it doesn't mean that it is authenticated. DNSSEC, at the moment is
> unable at the moment to protect his last mile and your draft is
> supposed to provide this protection but at the moment it does not.
> 
> validate or have a trusted path to a validator. But that's all
> unrelated to this draft. This drafts is about encrypting (and maybe
> possible

Well... I guess you are answering yourself .. I did not have any discussion about data integrity and also the second paragraph is all what I tried to tell you ... So I only answered your comment and explained that I did not talk about data integrity.  So not sure what is the problem here!?? :-/

> > Doesn't make sense... Your data is now all go through attacker, it
> doesn't matter for you? Then what privacy is supposed to be provided to
> the user?
> 
> Most attackers at the starbucks can only monitor what I send and
> receive, and do not actively send attacking packets to me.

I guess we are not on a same page... are we discussing about resolver privacy or the web application or email privacy?

Can you please explain to me what you expect to encrypt in resolver privacy scenario? 
I thought the encryption is only some domain names, IP address or the labels available on DNS server. The things that DNS server send it back to the node.

What you are talking here seems to be about web application privacy because if the first point doesn't fail (use opportunistic or whatever other approaches) then you are right that the attacker doesn't have the possibility to play MITM attack. 

But when you are talking about the resolver, you receive the IP address of one of attacker's server from this bad guy or good guy that can be inside your own network. 

For example,
You want to connect to google.com. your computer sends a request to resolver x with IP address 192.168.1.1. You will exchange the key information with this resolver. The good or bad guy called eve intercepts this communication and sends its own key and spoof the legitimate resolver IP address. Your poor node doesn't have any possibility to authenticate this resolver. So, your computer accepts eve's computer as the resolver and accepts any IP address eve gives to your computer. So, eve gives the IP address of one of her servers instead of google server. So, your computer sends all packets to this computer instead of sending it to the real google server and this computer forward it to real google server. So eve in this scenario only eavesdrops all the communications. Even though google server uses a valid certificate. But eve computer established this secure connection to google server. So your computer established a fake secure connection to google webserver while eve is in between and receives all the packet, decrypt it and then again send it to google server.

Your computer can never understand this problem since it has no possibility to authenticate this resolver. 

Did you solve privacy? Eve or who ever in between listened to all traffic. If you are using your home network and there is no other person who might be interested in your query send to this resolver, then why do you encrypt?
If there is a likelihood of having eavesdropper in the network, that eavesdropper can directly answer your query and claim to be a resolver so again why do you encrypt?
   
So what I think is that encryption and authentication both are necessary components for resolver DNS privacy.  

> >> able to verify the authenticity of data. I do not need to
> >> authenticate the resolver for that.
> >

But that person in wifi can also claim to be a resolver and directly receive your information. Like my example with eve. So I do not see any privacy protection. 

> > When you do not authenticate your resolver, what is important that
> some people do not see what you are browsing?
> 
> > I disagree with you and I think authentication and encryption
> together make sense. Even authentication alone is securer than
> encryption alone.
> 
> makes no sense to authenticate the local resolver. If you can, great
> and do it (and the draft says do it via some out-of-band method). But
> how on earth am I going to authenticate joe random coffeeshop from joe
> random attacker???

Nope, Joel already responded you. DNSSEC cannot protect you in this case. If it could, they could also use it now and there was no need for any other proposals.

> >> So this is all about encryption. We might want to authenticate with
> >> the network to encrypt with the good guy and not the bad guy. But if
> >> you're in a random untrusted network, you are going with an unknown
> >> guy anyway, so authentication matters much less.
> >
> > The question is what you are encrypting? Some domain names? Are they
> as important as you really need to do so?
> 
> Again, that is my call to make, not yours. There is a difference
> between the network owner/manager and the dozens of guests on the
> network. I trust one more than the other.

The important thing is whatever is in your query is not protected only by encryption because whoever you afraid to retrieve these data can introduced itself as a resolver and directly receive the data that you are afraid to expose it.

> > It is not the question of untrusted network, it is about pervasive
> monitoring. The good guy can be a network administrator or a
> government?!! who also interested to receive information passed through
> this network. He can easily play MITM attack since you trust this
> resolver in any case.
> 
> authentication of the local DNS server with authenticated encryption on
> the local wifi, helps me from nation state monitoring? That's not

Please see above.. this avoid repeating the same sentence.
Do not misinterpret what I said. I said both Encryption and Authentication is necessary and only encryption does not help because of the reasons I repeated in this message and last messages.

> > When you cannot authenticate a node, any node in even a good network
> can play this MITM attack. One example, you want to hide what you are
> browsing from your colleague... well, that is easy, your colleague will
> introduce his computer as a resolver and play MITM attack. Then who are
> you hiding the domain name or whatever stored in DNS resolver from?
> 
> Yes, you made this point a few times now. And I answered with
> explaining passive versus active attacks.

This is again my opinion. There is no passive attacks on resolvers. Your node once get some information and then if this information is wrong you are in trouble because you are connected via MITM. 
So the attacks is only once during when the time your node itself ask for a query. After that, everything is finished. And your node uses different approaches to connect for instance to a website or to a server. 
It appears that you think the resolver is last point of connection. The resolver is only the point which provide you information. It can be wrong or right. If it is right then the whole connection would be secure because you received the IP address of a correct server. Then the passive attack is for that part which is not related to resolver. 
The attacker might try to eavesdrop the data exchanged between you and a website. If the website is secure and you obtained the Ip address of this website securely from this resolver then the passive attack is protected as well but if there was MITM , you already have a MITM and encrypted connection to that website doesn't make sense otherwise that website uses a CA. Then your browser might give you a message that it cannot detect this IP certificate (because it is for attacker node). 
So this part is out of scope of resolver privacy scenario.

If this is not correct, please explain to me a passive attack scenario for resolver.

So again, I think passive attacks in resolver scenario tightly coupled to the first active attack and then whether the website or server that you obtained this IP address from, supports a valid CA.

> pointless. I'm at the mercy of the DHCP server, for which there is no
> authentication whatsoever anyway.

And any attack is possible.. this is why there is some new approaches like SAVI to protect DHCP

> > DNSSEC cannot do anything when your node doesn't know who is it
> connecting to... when you cannot verify the source of your message,
> data authenticity and encryption is not really useful. In any case,
> DNSSEC cannot help you in this scenario.
> 

Ok then I am an attacker, since you cannot authenticate me, I sign the data myself. This has data integrity. But it is the modified data and not what you expected to receive...

Hosnieh

---

From: Carsten Strotmann <[email-masked]>
Date: Tue, 19 Aug 2014 19:42:54 +0200

Hello Hosnieh,

Hosnieh Rafiee writes:

>
> Ok then I am an attacker, since you cannot authenticate me, I sign the
> data myself. This has data integrity. But it is the modified data and
> not what you expected to receive...

How can you sign DNSSEC data without being in the posession of the
private signing key(s) all the way to the root?

DNSSEC adds data integrity, and with one or more trust-anchors in the
resolver the client is able to validate the data, no matter which way
the data took.

The benefit of this proposal is to add encrption, so that not everyone
on the same network (wireless etc) can monitor the traffic.

Sure, the operator of the un-authenticated DNS resolver can monitor, but
now everyone could possibly monitor. With encryption, only the operator
could. Not optimal, but better.

And yes, some people care to keep their DNS queries private.

-- 
Carsten Strotmann
Email: [email-masked]
Blog: strotmann.de

---

From: 神明達哉 <[email-masked]>
Date: Tue, 19 Aug 2014 11:12:21 -0700

At Mon, 18 Aug 2014 10:59:22 -0700,
Paul Hoffman <[email-masked]> wrote:

> Greetings. I created a new proposal on a simple way to do DNS over
> TLS between stubs and resolvers. Comments are appreciated.

I have one few small comments.

- Section 2.1

   A security-oblivious stub resolver MAY use policy to allow
   unauthenticated encryption (which can possibly be intercepted by an
   on-path adversary) or authenticated encryption (which might prevent
   all DNS resolution if the server does not have correct authentication
   credentials) when contacting a recursive resolver using this
   protocol.

  Is this "security-oblivious stub" the concept defined in RFC 4033?
  If so, I think it's helpful to refer to the RFC explicitly.  And,
  even if so, I'm not sure how the "security-oblivious"ness
  matters in this context.  Some more explanation might be needed.

- Section 2.2

   A stub resolver cannot tell whether it is sending queries to a
   recursive resolver or to a DNS forwarder.  Therefore, a DNS forwarder
   that acts as a TLS server for DNS requests MUST also act as a TLS
   client for queries to its upstream recursive resolvers.

I wonder this 'MUST' may be too strong (or I don't fully understand
the sense of this MUST).  Since the upstream recursive resolver may or
may not support the TLS extension, the DNS forwarder may end up giving
up the resolution altogether.  But depending on the stub clients'
policy it may be still better to provide encryption between the stub
and the forwarder.

- General: perhaps related to the above points, I wonder what the stub
  resolver should do if it finds the recursive server(s) don't support
  the TLS extension.  It's probably just another policy matter (it can
  simply give up or live with resolution without encryption, etc), but
  I think it's worth noting explicitly.

--
JINMEI, Tatuya

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 Aug 2014 11:32:54 -0700

>  matters in this context.  Some more explanation might be needed.

This was just a leftover from a pre-draft when I was trying to deal with passing validation responses from resolver as well. It should simply have read "A stub resolver MAY..."

> policy it may be still better to provide encryption between the stub

Good catch. Proposed replacement to handle the case where the recursive resolver doesn't do TLS:

  A stub resolver cannot tell whether it is sending queries to a
  recursive resolver or to a DNS forwarder.  Therefore, a DNS forwarder
  that acts as a TLS server for DNS requests MUST also attempt to act as a TLS
  client for queries to its upstream recursive resolvers, but MAY
  use the normal DNS protocol on port 53 if an upstream recursive
  resolver does set up a TLS session.

>  I think it's worth noting explicitly.

Sure, let's be explicit. Proposed addition to the policy section:

If a recursive resolver does not respond on port 443 or set up a TLS session, the stub resolver MAY use the normal DNS protocol on port 53.

--Paul Hoffman

---

From: Jacob Appelbaum <[email-masked]>
Date: Tue, 19 Aug 2014 18:51:49 +0000

> If a recursive resolver does not respond on port 443 or set up a TLS
> session, the stub resolver MAY use the normal DNS protocol on port 53.
>

I'm not a fan of making it possible for an attacker to downgrade with
a single (non-cryptographically protected) TCP RST packet. If I
configure a resolver and declare it to be secure (and use it as such),
why not fail closed? Why not detect that as an attack or as outright
network censorship?

This seems to fail if there is an active attacker that blocks TLS
traffic - is there a way for the resolver to somehow learn in-band on
port 53 that this attack is happening?

All the best,
Jacob

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 Aug 2014 12:27:58 -0700

On Aug 19, 2014, at 11:51 AM, Jacob Appelbaum <[email-masked]> wrote:

> why not fail closed?

Because then hosts that use stub resolvers will not be able to use the DNS at all.

> Why not detect that as an attack or as outright
> network censorship?

We could add such detection, but only if the value outweighs the complexity and possible failure modes.

> port 53 that this attack is happening?

Probably, but you still haven't said what value there is in knowing that. A stub resolver has no log and no way of alerting anyone that it discovered something important.

Let me know if I'm missing something obvious.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Aug 2014 15:54:32 -0400 (EDT)

On Tue, 19 Aug 2014, Jacob Appelbaum wrote:

> a single (non-cryptographically protected) TCP RST packet.

So you would want DTLS?

The ALPN would also mark you censorship. In fact, just attempting to get
encrypted DNS in whatever way would mark you as such. If you tunnel all
of this over 443, they will just have to block all of 443.

An attacker on the local network could just forge the DHCP server. But
an attacker on-path on the internet could indeed send an RST packet.
However, most likely an attacker that can inject a packet can also
filter one out, so how common is the case of a non-local RST attacker?

If you are connecting to a remote DNS server for TLS, I would assume
you also have an out-of-band key (like a TLSA record) to authenticate
the resolver. You would detect this failure and know you are on a
hostile network.

> If I

I don't think the draft says anything about how to handle failure?

> port 53 that this attack is happening?

If you would publish a TLSA record, then yes. eg:

_443._tcp.8.8.8.8-in-addr.arpa IN TLSA <google-dns-pubkey>

Seeing the responses so far, I think the document needs to be much
clearer with respects to "last mile" versus "remote DNS server"
encryption.

Paul

---

From: Jacob Appelbaum <[email-masked]>
Date: Tue, 19 Aug 2014 20:02:38 +0000

> Because then hosts that use stub resolvers will not be able to use the DNS

That is correct and that is exactly what I expect when my network is
attacking me. Rather than leaking that I'm being visited an ad name
that implies I've visited a gay dating site, I want it to fail closed.
If I declare it as secure, I want it to remain secure - where the
security here is all about *confidentiality* and DNSSEC does the rest
with regard to integrity, etc.

> and possible failure modes.

If the TLS connection fails to complete (authenicated or not), it
should be as simple as returning something like E_CENSORSHIP_DETECTED.
An error like "Unable to connect securely to resolver, please contact
your ISP" would be fine.

Most OSes don't do anything remotely helpful when DNS fails. It might
be nice if that failure mode was privacy preserving...

> Probably, but you still haven't said what value there is in knowing that. A
> stub resolver has no log and no way of alerting anyone that it discovered
> something important.

If my resolver allows upgrading to a secure method of communication,
I'd like to know. Furthermore, I'd like to automatically upgrade to
that secure communications path if it was available. An OS could probe
for a specific record type - similar to say, version.txt.

e.g.: nslookup -q=txt -class=CHAOS query.privacy.bind.

It could even learn the likely fingerprint of the server ala DANE, for example.

> Let me know if I'm missing something obvious.

Hope that helps.

All the best,
Jacob

---

From: Jacob Appelbaum <[email-masked]>
Date: Tue, 19 Aug 2014 20:14:51 +0000

>> a single (non-cryptographically protected) TCP RST packet.

It depends; perhaps? An on-path attacker can mess with TCP and UDP by
dropping. There isn't much to be done there. An off-path attacker (eg:
QUANTUMINSERT) is a Machine-On-The-Side and in that case, TCP still
falls over. DTLS may do better, I'm not sure.

> of this over 443, they will just have to block all of 443.

I'm not clear that this is true - I think encrypting all DNS provides
a kind of herd immunity: this is the way the network works and major
DNS providers will support a secure option. If only those that need
it, ask for it, then yes, it is a distingushing feature that is likely
a problem.

And yes, they'd have to block all of 443. This doesn't happen as often
as we'd think, I suspect. Also, if they have a single switch - they
kill it for *everyone* and not only for selected folks by keyword.
This creates a lot of social pressure.

In my experience with Tor being blocked in Iran - it is much easier to
block Tor than it is to block Google. This isn't just technical. It is
also about deployment - the one everyone uses is normal and not as
acceptable to block all of the time.

>
> An attacker on the local network could just forge the DHCP server.

A lot of people manually set their DNS servers in censorship prone
countries. I've heard that Google selected 8.8.8.8 for cultural
reasons in addition to being a nice short number.

> But

An attacker can inject if they've seen the handshake - they don't have
to be on-path to tear it down.

> filter one out, so how common is the case of a non-local RST attacker?

I think it is pretty real:

  https://en.wikipedia.org/wiki/QUANTUMINSERT#QUANTUM_attacks

To compare - Iran has edge routers that are often hostile (on-path)
and the NSA/GCHQ have that at defense networks, as well as off-path
injection all around the world.

We have to deal with both kinds of attackers, I think. Jerks. :(

> the resolver. You would detect this failure and know you are on a

Yes, that sounds about right.

> I don't think the draft says anything about how to handle failure?

It should. We should actually handle attacks in the wild and not treat
them as rare flowers that are never expected to be found.

> _443._tcp.8.8.8.8-in-addr.arpa IN TLSA <google-dns-pubkey>

I think that is a good start but I was thinking about service
discovery - that is I have to know to look for that record.

> clearer with respects to "last mile" versus "remote DNS server"

They're essentially the same problem when you use OpenDNS, Google's
public DNS, Sonic.net's awesome resolvers, and so on.

All the best,
Jacob

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Aug 2014 17:01:14 -0400 (EDT)

>  resolver does set up a TLS session.

A resolver at a coffee shop is mostly concerned about protecting the DNS
in the public wifi, and might not worry at all about its DSL uplink,
especially when it has no real reason to trust its own uplink. So I
would just make it very generic:

   a DNS forwarder that acts as a TLS server for DNS requests SHOULD
   attempt to use TLS with its upstream resolver(s) to maximize the
   anonymity of its stub clients.

> If a recursive resolver does not respond on port 443 or set up a TLS session, the stub resolver MAY use the normal DNS protocol on port 53.

MAY sounds a little odd here. If there is no preconfiguration for
authenticating this resolver, I don't think we should advise
stubs to refuse to do DNS completely, which is what the MAY is
suggesting as a valid option. (this is breaking the "opportunistic
security design pattern recommendation advise" :)

How about:

 	If a recursive resolver for which an authentication method is
 	available does not respond on port 443 or fails to set up a TLS
 	session, the stub resolver SHOULD NOT use that resolver over
 	unencrypted DNS using port 53. If no authentication method is
 	available for the recusive resolver, the stub resolver SHOULD
 	fallback to using cleartext DNS on port 53.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 Aug 2014 16:19:12 -0700

[[ Combined PaulW's and Jacob's responses ]]

>  anonymity of its stub clients.

I'm fine with that as a replacement for my suggestion above.

> 	fallback to using cleartext DNS on port 53.

That seems mixed up. I think the policies we want to list are:

a) Must have authenticated TLS, otherwise don't get any DNS responses

b) Try to do authenticated TLS, but use unauthenticated TLS if possible, otherwise don't get any DNS responses

c) Try to do authenticated TLS, but use unauthenticated TLS if possible, but allow cleartext on port 53 if TLS cannot be established

Does this seem like the whole list?

> with regard to integrity, etc.

I think that would policy (a) listed above. Does that work for you?

> should be as simple as returning something like E_CENSORSHIP_DETECTED.

It is reasonable for the policy to suggest that a later API might be able to detect which level of protection, if any, the user has gotten. 

> An error like "Unable to connect securely to resolver, please contact

And you might want to only use applications that use that later API.

> be nice if that failure mode was privacy preserving...

It might be, yes.

> It could even learn the likely fingerprint of the server ala DANE, for example.

Once we have privacy for all types of stub resolvers, it could certainly be useful for a few people who have security-aware validating stub resolvers to have that information. It is an easy follow-on for those who care about it.

--Paul Hoffman

---

From: Jacob Appelbaum <[email-masked]>
Date: Wed, 20 Aug 2014 13:30:03 +0000

> I'm fine with that as a replacement for my suggestion above.

I'd switch this to say 'confidentiality' rather than anonymity.
Anonymity is a much stronger claim which I adore but it seems out of
place here.

> c) Try to do authenticated TLS, but use unauthenticated TLS if possible, but
> allow cleartext on port 53 if TLS cannot be established
>

d) Don't do TLS at all, only try cleartext on port 53 (the sad default
state of the internet today)

e) All the other DNS privacy stuff - eg: OpenDNS's encrypted DNS
stuff, djb's other work, etc.

>>> Because then hosts that use stub resolvers will not be able to use the
>>> DNS
>>> at all.
>>

Yes. It is perfectly fine. If it was the default policy when
configuring a TLS aware resolver unless configured to be *less secure*
explicitly, certainly so.

>>> We could add such detection, but only if the value outweighs the
>>> complexity
>>> and possible failure modes.
>>
> It is reasonable for the policy to suggest that a later API might be able to
> detect which level of protection, if any, the user has gotten.

I like the idea of a notice but I prefer the idea of explicitly
ensuring that one has configured a privacy DNS resolver - thus - it
seems the API needs to consider this from the start.

> Once we have privacy for all types of stub resolvers, it could certainly be
> useful for a few people who have security-aware validating stub resolvers to
> have that information. It is an easy follow-on for those who care about it.
>

I think a key thing is that we need a way to discover that an already
configured stub resolver supports this kind of confidentiality. When
the stub software updates, the resolver that is already configured
could be upgraded to use the privacy preserving path, for example.

All the best,
Jacob

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Aug 2014 07:53:45 -0700

> Anonymity is a much stronger claim which I adore but it seems out of

Good catch, yes.

> state of the internet today)

Hrm. That is not really a policy choice for *this draft*, but I see your point. I'll add it.

> stuff, djb's other work, etc.

I can't list a policy that I can't cleanly describe. The OpenDNS folks still haven't produced a stable description of their protocol that I can find; if they have one, I'm happy to list it. DNScurve doesn't work for stub-to-recursive, I don't believe; only recursive-to-authoritative.

> explicitly, certainly so.

The document is not going to list what a default policy should be.

> seems the API needs to consider this from the start.

If you want to work on an API, that's great. APIs for security have a long history of bringing down protocols in the IETF, I don't want the API to hold up the protocol. If you get started on it before this document is finished, I'm happy to point to your work-in-progress.

> could be upgraded to use the privacy preserving path, for example.

That would take an API. I really don't want to force that into this document, but as I said above, if you or someone wants to tackle the API question, I'm happy to point to it.

--Paul Hoffman

---

From: Jacob Appelbaum <[email-masked]>
Date: Wed, 20 Aug 2014 15:11:40 +0000

On 8/20/14, Paul Hoffman <[email-masked]> wrote:
>>>>> Good catch. Proposed replacement to handle the case where the
>>>>> recursive
>>>>> resolver doesn't do TLS:
>>>>>
>>>>> that acts as a TLS server for DNS requests MUST also attempt to act as
>>>>> a
>>>>> TLS

Ok. Sounds great - I'm looking forward to reading the updated draft!

> I can't list a policy that I can't cleanly describe. The OpenDNS folks still
> haven't produced a stable description of their protocol that I can find; if
> they have one, I'm happy to list it. DNScurve doesn't work for
> stub-to-recursive, I don't believe; only recursive-to-authoritative.
>

Really? I'm surprised. I've cc'ed David Ulevitch - perhaps he or
someone at OpenDNS can chime in with something helpful here?

> The document is not going to list what a default policy should be.

OK.

Perhaps it would be useful to state assumptions about what a different
policy means?

If a user manually configures a confidential server (and loads the
fingerprint or learns the key with DANE) - it is expected that an
implementation MUST fail closed? I think this is what happens when you
use the OpenDNS resolver with their crypto implementation. I don't
think it falls back to plaintext.

> If you want to work on an API, that's great. APIs for security have a long
> history of bringing down protocols in the IETF, I don't want the API to hold
> up the protocol. If you get started on it before this document is finished,
> I'm happy to point to your work-in-progress.

I think you have a compelling point. Let us split the tasks. :)

>>>>> Probably, but you still haven't said what value there is in knowing
>>>>> that.
>>>>> A
> That would take an API. I really don't want to force that into this
> document, but as I said above, if you or someone wants to tackle the API
> question, I'm happy to point to it.
>

Hrm - would it? I think that we could just add something like "stub
resolvers SHOULD automatically request the following DANE record
foo.bar.baaz.keys.whatver to learn the key for their encrypted
resolver. Recursive resolvers supporting DNSSEC MUST verify that this
record is correctly signed."

Does it need to be more complicated than that? I mean, we'd need to
agree on the record but I suppose there is a PTR record name that
would fit here, no?

All the best,
Jacob

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 20 Aug 2014 17:20:36 +0200

On Wed, Aug 20, 2014 at 03:11:40PM +0000,
 Jacob Appelbaum <[email-masked]> wrote 
 a message of 236 lines which said:

> > DNScurve doesn't work for stub-to-recursive, I don't believe; only
> > recursive-to-authoritative.
> >
> 
> Really? 

Yes.

> I'm surprised. I've cc'ed David Ulevitch - perhaps he or someone at
> OpenDNS can chime in with something helpful here?

You probably mix DNScurve with its derivative DNScrypt.

---

From: Hosnieh Rafiee <[email-masked]>
Date: Wed, 20 Aug 2014 15:40:38 +0000

> You probably mix DNScurve with its derivative DNScrypt.

DNScrypt is dependent to DNSSEC. And at the moment doesn't support it as well.

---

From: 神明達哉 <[email-masked]>
Date: Wed, 20 Aug 2014 08:44:31 -0700

At Tue, 19 Aug 2014 11:32:54 -0700,

> This was just a leftover from a pre-draft when I was trying to deal with passing validation responses from resolver as well. It should simply have read "A stub resolver MAY..."

Ah, okay.

> > I wonder this 'MUST' may be too strong
[...]
>   resolver does set up a TLS session.

This works for me (I realize there's a followup discussion regarding
the possibility of downgrade attacks, on which I don't have a strong
opinion yet).

> If a recursive resolver does not respond on port 443 or set up a TLS session, the stub resolver MAY use the normal DNS protocol on port 53.

Works for me, too.

--
JINMEI, Tatuya

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Aug 2014 11:43:55 -0700

On Aug 20, 2014, at 11:34 AM, David Ulevitch <[email-masked]> wrote:

> DNSCrypt has been well-described and is in use by millions of people today across a number of implementations.  Details available here: http://dnscrypt.org/  -- We can certainly do better.

Please do, given that there is nothing on that page that describes the actual protocol. 

> Happy to help push it along to a standard.

Please note that no one here was suggesting that, yet.

> I'll have one of our engineers get more involved in this list.  Thanks for the poke Jacob.

Great. Given your level of deployment, us knowing what the actual protocol is would be useful.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Aug 2014 12:07:22 -0700

> Perhaps it would be useful to state assumptions about what a different

I have no idea what you mean, but I suspect you do. Proposed wording would be appreciated.

> think it falls back to plaintext.

It would be good to see their actual protocol design; it sounds like that is forthcoming.

> Hrm - would it?

Yes, it really would.

> I think that we could just add something like "stub

That would only work for security-aware, validating stub resolvers, which is currently a teeny minority of what is deployed. Further, that would also imply that the stub resolver is also recursive in order to find the DANE record; at that point, this protocol is not needed.

> Does it need to be more complicated than that?

Yes, unfortunately. A non-validating stub resolver that needs a key for the TLS server needs to get it out of band, I believe. I'm happy to hear other opinions though, because it would make getting all the way to authenticated encryption more likely.

> I mean, we'd need to

No, not yet. There is even less DNSSEC coverage in the reverse tree than there is for normal names.

Updated draft with recent suggestions coming out soon.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Aug 2014 12:16:18 -0700

Thanks for the comments so far, clearly there is more to come. Even if this group doesn't go for this design, I think the discussion will be useful to most of the designs we have seen so far.

--Paul Hoffman

A new version of I-D, draft-hoffman-dns-tls-stub-01.txt
has been successfully submitted by Paul Hoffman and posted to the
IETF repository.

Name:		draft-hoffman-dns-tls-stub
Revision:	01
Title:		Using TLS for Privacy Between DNS Stub and Recursive Resolvers
Document date:	2014-08-20
Group:		Individual Submission
Pages:		7
URL:            http://www.ietf.org/internet-drafts/draft-hoffman-dns-tls-stub-01.txt
Status:         https://datatracker.ietf.org/doc/draft-hoffman-dns-tls-stub/
Htmlized:       http://tools.ietf.org/html/draft-hoffman-dns-tls-stub-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-hoffman-dns-tls-stub-01

Abstract:

---

From: David Ulevitch <[email-masked]>
Date: Wed, 20 Aug 2014 11:34:49 -0700

> someone at OpenDNS can chime in with something helpful here?

DNSCrypt has been well-described and is in use by millions of people today
across a number of implementations.  Details available here:
http://dnscrypt.org/  -- We can certainly do better. Happy to help push it
along to a standard.

I'll have one of our engineers get more involved in this list.  Thanks for
the poke Jacob.

-David

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 27 Aug 2014 12:46:41 -0700

> resolver the client is able to validate the data, no matter which way

So, there is some confusion here I think so we need to be clear about a
few things.  We're talking about privacy, and in this context
stub-to-resolver entirely.  There are two forms of
integrity/authentication going on and they need to be clearly separated
but I keep seeing them being thrown together.

DNSSEC absolutely helps you ensure that the end data you got is "good"
from the notion of the publisher.

But it doesn't help you to identify the public key of the resolver
you're using to query for those results.  So it doesn't help you ensure
you're encrypting your packets to the right destination.  And DNSSEC may
ensure you have the right data, but it doesn't help you determine if you
really did get it in a way that no one else but you, the coffee shop
owner, and the final destination could see.  And this is the important
bit: in the context of the discussion, we are only talking about
verifying the public key of the resolver in order to implement privacy;
Clearly DNSSEC has solved authenticating the data itself and that's not
in question.  I think most people understand this difference (I hope).

But here's the thing that is keeping me awake at nights in this topic:
we keep saying that "un-authenticated encryption is better than no
encryption".  And I do generally think this is true.  At least you're
only transmitting your data to one potentially bad person (the one
you've done a key negotiation with) rather than letting anyone with 100
feet view the data.

But then, stepping back, you have to ask yourself: what's the likely
threat model of everyone in 100 feet trying to attack you?  If we really
are worried about protecting people at starbucks, what's the likelyhood
of 2 people in starbucks trying to sniff your private dns lookups at the
same time?  Probably super-duper low.  So, are we really protecting you
at all if the one bad person in the coffee shop is able to convince you
it's the local resolver?  IE, if we blindly assume that whatever key we
get is ok then we're buying ourselves very minimal protection against
the few opponents within spitting distance of a wireless box.  Likely
there will be just one, and it'll likely succeed in defeating your
encryption.

Now, in larger venues where are there are potentially lots and lots of
people that are targeting an environment for sniffing, say at an IETF
convention where we're very good at overwhelming infrastructure, then
the likelyhood of having multiple malicious eves goes way up and maybe
we've achieved a bit of protection by transmitting our dns request data
to just one advocacy instead of them all.

But what's the solution?  How do we authenticate that resolver?  PKIX
won't help us, as there is no name.  DNSSEC won't help us, as half the
time you're behind a nat so the reverse tree can't be used [ipv6
actually might help here].  Leap of faith is probably better than
nothing if you frequent that coffee shop.  I don't think secure dhcp has
gotten that far, but I'm admittedly out of touch.

We simply keep moving this chicken/egg problem of secure bootstrapping
from one protocol to the next.  It's like one egg that keeps changing
chickens.

-- 
Wes Hardaker
Parsons

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 27 Aug 2014 13:05:38 -0700

On Aug 27, 2014, at 12:46 PM, Wes Hardaker <[email-masked]> wrote:

> won't help us, as there is no name.  

Say what? That draft clearly says that the resolver can have a PKIX certificate with its IP address as the name.

> DNSSEC won't help us, as half the
> actually might help here].  

Right, but irrelevant, since the stub is assumed not to be a validating stub because so few are.

> Leap of faith is probably better than

Secure DHCP is just moving the egg around. The likelihood that you have the coffee shop's DHCP server's credentials are zero.

You also forgot other options, such as preshared signing key. That would work fine for enterprises or ISPs with a help desk and a few thousand users. "Paste this into that dialog on your computer" works OK. But PKIX with IP addresses is probably more scalable.

> from one protocol to the next.  It's like one egg that keeps changing

Please look at the draft again; I don't think it is as bad as you are saying.

--Paul Hoffman

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Aug 2014 12:26:01 +1000

> in question.  I think most people understand this difference (I hope).

Actually DNSSEC could give you the key of the resolver securely
provided it has a public address.  Publish a KEY record signed in
the DNS under in-addr.arpa or ip6.arpa.  If need to we define flag
bits to say it is for this purpose.  For private addresses you need
to have a trust anchor for the private part of the reverse tree or
use leap of faith.

This also works for any authoritative server.

Alternatively we could allocate a new type to hold the key material.

You can't hide that you are talking to a resolver so there is no
need to encrypt the lookups for the KEY, DNSKEY, DS lookups required
to validate the KEY.

> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 29 Aug 2014 05:26:21 -0700

> to have a trust anchor for the private part of the reverse tree or

Yes, that's what I was saying...  I was just following it by "there are
a huge number of private-address resolvers in the real world".

-- 
Wes Hardaker
Parsons

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 29 Aug 2014 05:30:05 -0700

Paul Hoffman <[email-masked]> writes:

> Say what? That draft clearly says that the resolver can have a PKIX
> certificate with its IP address as the name.

So we're going to issue a gazillion PKIX certs for 10.0.0.1?

> The likelihood that you have the coffee shop's DHCP server's
> credentials are zero.

I think I was implying that so we agree :-)

> You also forgot other options, such as preshared signing key. That
> would work fine for enterprises or ISPs with a help desk and a few
> thousand users. "Paste this into that dialog on your computer" works
> OK. But PKIX with IP addresses is probably more scalable.

Well, I thought about the coffee shop sign (here's our WPA password
along with our resolver's magic verification string).

-- 
Wes Hardaker
Parsons

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 29 Aug 2014 07:59:35 -0700

> So we're going to issue a gazillion PKIX certs for 10.0.0.1?

Sure, why not? If you have an internal CA that is trusted by your users, there are no different issues for it writing certs for a private address that might overlap with systems in different address spaces than there is for it writing certs for private names that might overlap with systems in different namespaces.

> I think I was implying that so we agree :-)

Good.

> along with our resolver's magic verification string).

Sure, that would work. But more importantly, if what we are trying for is opportunistic security, the MITM would have to be in the coffee shop, unless the coffee shop's DHCP server says that the recursive resolver is on the public internet and that resolver doesn't have a valid cert.

--Paul Hoffman

---

From: John Heidemann <[email-masked]>
Date: Fri, 29 Aug 2014 21:56:55 -0700

On Wed, 27 Aug 2014 12:46:41 -0700, Wes Hardaker wrote: 
>...

I want to take a step back to consider a different case.

The complaint here is that it is tough to authenticate some arbitrary
resolver handed to you from DHCP because of person-in-the-middle.  Yes,
that's a hard problem.

"Doctor, it hurts when I do this." "Don't *do* that."

If you aren't willing to trust a resolver from DHCP, one could use a
public DNS resolver, acquire its certificate out-of-band, and check it.
I.e., do certificate pinning on the TLS certificate you plan to use for
DNS.

I'm told there are IP addresses of a public resolver spraypainted on
walls in Turkey you could try.  (If that or some other provider
supported TLS for DNS.)

   -John

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 30 Aug 2014 01:08:55 -0400

> "Doctor, it hurts when I do this." "Don't *do* that."

Exactly.

Step one to better DNS security is NEVER EVER USE THE DHCP DNS SERVER

The only exception being finding a path to your intended DNS server.

People keep trying to fix DNS security by applying the security that
fits a broken 30 year old model designed at a time when absolutely
nobody knew what they were doing.

> I.e., do certificate pinning on the TLS certificate you plan to use for

Hang on, the machine could do that but lets keep the user out of this
please? Any time people suggest complicated configuration then its a
protocol nobody will ever use.

The machine can do those steps but not the human. It has to be
frictionless or it will never get used.

> walls in Turkey you could try.  (If that or some other provider

Well the spray-painted one got blocked so we need to do a little more
than that.

In my Private-DNS scheme the user binds their account to a security
provider that potentially provides a raft of security services. This
is a one time event per user until they change providers. They then
bind each of their machines to their account using a simple, easy to
use mechanism.

This is not doing TLS pinning, but thats because I didn't find TLS
provides much leverage except for initial configuration.