Subject: [dns-privacy] DNS Privacy requirements and PRIVATE-DNS

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 21 Mar 2014 17:16:06 -0400

I have a first cut of a use cases and requirements draft. It also
contains a description of my proposed solution.

http://www.ietf.org/id/draft-hallambaker-dnse-00.txt

I have not gone through and audited the proposal against the
requirements but I am pretty sure it meets them all.

The key is the division of the problem between the service connection
service and the query hosts. If we divide up the problem that way so
that the two are independent services that can be implemented
separately if desired, I have enough flexibility to meet pretty much
any set of requirements people want to throw at it. And none of the
consequences show through the query host part.

So looking at the way this might deploy on a service like
dnsbycomodo.com, the dns publication constellation does not need to be
affected very much. All I need to do is to rack up some Service
Connection hosts that can handle the new work. I have to deploy the
new message encapsulation format for the query hosts but that just
means doing a few simple symmetric crypto steps on each request. I
don't think its going to affect the server load at all.

-- 
Website: http://hallambaker.com/

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Fri, 21 Mar 2014 22:59:14 +0100

Hi Phillip,

I just skimmed your draft. Just a quick comment...

>[R-C-AFIRST]
         Protect the confidentiality of request and response data 
         against an active attacker after first contact.

   >   [R-C-ACTIVE]
         Protect the confidentiality of request and response data 
         against an active attacker on every contact.

>     [R-C-TRAFFIC]
         Protect the contents of messages from being disclosed by an 
         external attacker through traffic analysis.

I do not see any real difference between protecting the data confidentiality
or protecting the message content. If you mean protecting the IP address of
requestor or something like that, I guess not possible. If you mean
something else then it is not really clear. I do not see any difference
between external attacker and active attacker... 

Section 4, why you only consider UDP? Why not also TCP?
I guess it makes sense to include any problem that is the cause of using
TCP.

> Under certain network conditions attempts to reach the PRIVATE-DNS 
   service may fail due to constraints imposed by firewalls or through 
   attempted censorship. Under these conditions, HTTP [RFC2616] MAY be 
   used as an alternative transport as follows:

I am really curious to know what is the example network that you're talking
about that close port 53 on firewall but thinks that port 80 is more
important and should keep it open.  It might appear only on web servers but
I do not think this might happen on the any network that uses firewall.
Right??

Hosnieh

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 21 Mar 2014 21:36:08 -0400

> between external attacker and active attacker...

These are hard to word precisely. I spent several days on those
definitions as it was.

I think the traffic requirement is clearly distinct from the message
confidentiality requirements. But the definition should probably use
terms like 'inference'.

Secure only against passive attacks, secure after first contact and
always secure represent progressively stricter security requirements.
The resources required to provide security are considerably greater as
well.

Which level of security you require depends on your use case and
especially whether you are talking about the client-resolver
interaction or the resolver-authoritative interaction.

> I guess it makes sense to include any problem that is the cause of using

If it is going to be a drop in replacement for DNS it has to be just
as fast. The Google folk are into shaving milliseconds off the latency
of Chrome.

The UDP scheme should work in over 97% of network environments and the
other 3% tend to be places where the network will be horrid anyway.

> I do not think this might happen on the any network that uses firewall.

There are many networks where TCP port 53 is blocked for outbound traffic.

Networks where port 80 is blocked outbound probably don't matter very
much for this project because the user isn't going to be going outside
the local network anyway.

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sun, 23 Mar 2014 10:01:38 +0100

> > I do not see any real difference between protecting the data
> > confidentiality or protecting the message content. If you mean
> > protecting the IP address of requestor or something like that, I guess
> > not possible. If you mean something else then it is not really clear.
> > I do not see any difference between external attacker and active
attacker...
> These are hard to word precisely. I spent several days on those
definitions as
> it was.
> confidentiality requirements. But the definition should probably use terms
> like 'inference'.

True, but your definition is not what you meant. If you mean confidentiality
of message headers and the confidentiality of message content. Then what you
wrote is not clearly convey that meaning.

> Which level of security you require depends on your use case and
especially
> whether you are talking about the client-resolver interaction or the
resolver-
> authoritative interaction.

It might be but it also depends on your definition as well.  In one scenario
you can consider the same situation as exist for client to resolver. This is
true especially when the recursive resolver really does not have any clear
secure way to authenticate the authoritative DNS server. Not all
authoritative DNS servers are known to all recursive resolvers. 
In other words, the use case for client to resolver is likely to overlap the
use case for recursive resolver to authoritative resolver, if and if, we are
only concern the passive attack. 
 
> > I am really curious to know what is the example network that you're
> > talking about that close port 53 on firewall but thinks that port 80
> > is more important and should keep it open.  It might appear only on
> > web servers but I do not think this might happen on the any network that
> uses firewall.
> > Right??
> 
> much for this project because the user isn't going to be going outside the
local
> network anyway.

If the user are not going to outside of their local network, then I would
consider this as an isolated network and they either have local DNS resolver
or they do not have at all. If they have and it is in the same network as
other nodes, they need to keep open port 53.  So, it is unlikely that the
situation you're concerned about ever happens. I am not really convinced
about your definition here.

Hosnieh

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 23 Mar 2014 09:22:28 -0400

> wrote is not clearly convey that meaning.

Privacy leakage from the IP header and encapsulation is actually
another requirement I don't distinguish (yet). I will add it.

The point of distinguishing these requirements is that different
approaches meet only some of them. It is a tradeoff.

> only concern the passive attack.

The purpose of requirements is to enable an informed discussion of proposals.

A proposal does not have to meet every possible requirement. But
someone evaluating the proposal has to understand the full set of
requirements that might be relevant.

The requirements that are not met are going to end up as security
considerations, thats all.

Worry about the complexity of proposals, not requirements. Simplifying
a proposal is usually a good thing. Simplifying requirements is always
introducing a risk of making a mistake. Here we have a process where
the gnomes of Fort Meade are going to be looking at ways to sabotage
the effort. Manipulating requirements is a favorite trick of theirs.

Authenticating the client/resolver is essentially cost free. Which
makes it completely different to authenticating the
resolver/authoritative. The only reason to not authenticate the client
is if you don't want to know who is asking the question.

The approach proposed in PRIVATE-DNS is always secure against passive
attacks on the service connection service and secure against active or
passive attacks on the query service.

If someone wanted to eliminate the active attack on the service
connection service (SXS) that is easy because SXS is running over TLS
and so we can use straight PKIX or DANE type approaches or we can cut
a new DNS record. But that is not something that would worry me at
this point. We know that we can do it if that turns out to be
desirable and that we have options.

The only impact that requirement has right now is that it is one of
the reasons I want to be able to return longer DNS responses if needed
since I might end up exchanging certs.

Don't assume that fast setup of the SXS is a requirement in the
recursive/authoritative loop. A cache miss is actually a rare event
for a public DNS service. And most cases it means the domain does not
exist.

The point of requirements engineering is to understand the underlying
problem. The IETF approach of twisting the requirements to a
particular limited view of the problem is doing it exactly wrong.

> about your definition here.

A lot of networks turn out to have transparent MITM DNS servers that
restrict DNS traffic on port 53/UDP and block port 53/TCP completely.

It sucks but thats the constraint.

What I am saying in the proposal is that we eliminate the 53/TCP
fallback through a combination of support for multiple UDP responses
and fallback to a HTTP transport that is more or less guaranteed to
work in any circumstance.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 24 Mar 2014 12:15:29 +0100

On Fri, Mar 21, 2014 at 05:16:06PM -0400,
 Phillip Hallam-Baker <[email-masked]> wrote 

> http://www.ietf.org/id/draft-hallambaker-dnse-00.txt

My main concern with this draft is that it carries both a set of
requirments and a possible solution. I suggest to split it in two.

On the requirments:

>     [R-PSPOOF]
>         Prevent spoofing of DNS responses by passive attack

I do not see how you can spoof DNS while being purely passive. Do you
refer to an off-the-path active attacker?

Editorial:

> Deployment of the new security mechanism compliments DNSSEC.

Complements? (I know I do not speak english but I'm nevertheless
confused.)