[Dnssec-trigger] New dnssec-trigger NM dispatcher script

[Pavel Simerda]

----- Original Message -----
> From: "Paul Wouters" <paul at nohats.ca>
> To: "Tomas Hozza" <thozza at redhat.com>
> Cc: dnssec-trigger at NLnetLabs.nl, "Juraj Marko" <jmarko at redhat.com>, "Pavel Simerda" <psimerda at redhat.com>, "Paul
> Wouters" <pwouters at redhat.com>
> Sent: Wednesday, January 22, 2014 7:00:32 PM
> Subject: Re: [Dnssec-trigger] New dnssec-trigger NM dispatcher script
> 
> On Wed, 22 Jan 2014, Tomas Hozza wrote:
> 
> > What about the "secured corporate" wifi network situation I described
> > before?
> > I personally see a use case also in wifi networks, but I agree that it is
> > hard
> > to come up with a really good solution. I'm willing to improve it in some
> > way
> > if you have any constructive ideas (in the constraints of current
> > possibilities),
> > but stopping the addition of forward zones for wifi connections completely
> > is
> > also not a good idea by my opinion.
> 
> > I agree with this. Unfortunately at the moment it is not possible in the
> > NM UI and will require even further NM integration (which is planned,
> > but will not happen over night).
> >
> > The plan is that the configuration file could be at least partially
> > used by NM in the future. This way we will be able to at least provide some
> > backward compatibility with the current solution that uses dnssec-trigger.
> > Therefore we think it is not a good approach to leave the configuration
> > solely in dnssec-trigger dispatcher script.
> >
> > The motivation here is to improve the current situation due to some
> > issues I described before, in the constraints of current possibilities,
> > rather than implement the best possible solution later on (which will
> > anyway happen).
> 
> Let me try and summarize what I think is the problem.
> 
> You have interpreted the "domain" entry in /etc/resolv.conf as being the
> LAN's domain and the nameservers from /etc/resolv.conf as being the IP
> addresses of the nameservers that can resolve the "domain".

I see what you mean but let me write it correctly, as we don't use /etc/resolv.conf at all:

We are using NetworkManager's per-connection nameserver list and domain search list as the list of zones and their respective nameservers.

This is the same NetworkManager is doing with their dnsmasq plugin and it's generally called the *split DNS* feature which is necessary to properly talk to local resources on multiple networks. The split DNS feature requires a list of domains and a list of respective nameservers. The protocols used by NetworkManager (e.g. DHCP) typically provide one list of local domain in the DHCP search domain list. Because of that, NetworkManager doesn't distinguish those lists.

Without the split DNS feature, NetworkManager magically guesses which of the nameservers should be used to get the best results. Just testing the VPN case, it redirects *all* DNS queries to the VPN name servers even though the VPN isn't designated as a default connection. In fact it mixes all DNS servers it finds together. This is a bad privacy issue at the least as that way the local system leaks visited servers to the VPN name servers. Considering what you see as bad security issues, this is probably one of them as technically any query can be posted to any of the name servers.

> However, that is not what those entries mean. The "domain" entry means
> that if you are going to send an unqualified (non-FQDN) query, and you
> don't get a result, you may try again my apending the "domain" entry.
> The IP's of nameservers are nothing more than the IP of nameservers.
> They have no relationship to the "domain" entry whatsoever.
> On modern systems, these values are populated by DHCP.
> 
> Thse two interpretations are different, which is the source of the
> security issues.

It's pretty common to identify the security issues and compare them to the status quo instead of making vague claims.

I'm afraid that you are focusing on something that technically constitutes a security issue but doesn't affect the security a much. While it may sound appealing to remove the behavior of accepting zone-specific nameservers from untrusted sources, you will still accept *any* IP subnet and thus the network's DHCP server can choose you to deliver packets for specific IPs to the network's router. The security of dynamic configuration would have to be evaluated as a whole, not by just suspecting a security issue. But we have a solution for you anyway, please read on.

In my opinion, the world's most important use case for DNSSEC is to use DNSSEC as a glue for other security protocols, not merely as a means to receive the correct A/AAAA records. And for that security to work, the clients must support DNSSEC, DANE and finally TLSA. In this scenario you need a supporting server, a local validating resolver and a supporting user agent. Support for that should have been enabled in distributions years ago and we are still nowhere. The existing solution is not even usable for developer testing unless one wants to dedicate a machine to that. Adding a contact from CZ.NIC where they're working on server-side DNSSEC and tools like DNSSEC validation icon for Firefox.

Authentication of all DNS queries even for unsupporting applications is a very appealing feature of DNSSEC and Unbound but that's where the issues with the real world arise. I like this possible feature just as you do but I still think the feature above allowing stuff like DANE is more important and less conflicting and 

> Sometimes, people have created relationships that _does_ equate these
> two different interpretations. So if you have a "domain" of
> "internal.redhat.com" and nameservers 1.2.3.4,5.6.7.8 than it is implied
> that you can lookup this custom non-world view domain using these
> nameservers. What you are suggesting is that _all_ networks are like
> this. While I am saying we should not _always_ assume this.
> 
> So the design work here is to come up with a scenario that:
> - Does not degrade security

What we can do is to disable passing the local forward zones from NetworkManager entirely by default and add a directive to /etc/dnssec.conf to enable it. Would that be acceptable to you?

> - Does not burden the user with making this choice

The solution doesn't burden the users. The configuration is in /etc/dnssec and is handled by the system administrator who acts according to the local security policy. What about accepting there is no one size that fits all and allowing the various systems to deploy varying degrees of security.

> We mentioned a few possibilities:
> - Assume ethernet connectivity implies the user's consent in trusting
>    the network, allowing the above assumption to be made

Rationale? Ethernet may well be as dangerous as any other connection. Most systems connect to Ethernet even when locked.

> - Assume VPN configurations always override LAN settings

Rationale? VPNs are often used just to access resources on a remote network, not always belonging to the same entity.

> - What to do with Wifi (we disagree here on what to do)

In any case, the contribution brings serious functionality improvements. With the two configuration directives in mind, you may well default to a very strict mode while allowing global configuration of whether to accept zones from connections and whether to enforce validation for them. That would keep dnssec-tigger at maximum security (and limited usability) while allowing for full usability (and security only for supporting applications) if configured so, making DNSSEC usable for people who at least want to test it out. Finer grained control should be IMO handled in NetworkManager. When NetworkManager provides the final lists of domains to be used as local forward zones, dnssec-trigger would switch to using those.

I propose to ignore connection types in the script that just copies over NetworkManager's local forward zones and handle the details inside NetworkManager. Until that is done, the /etc/dnssec.conf directives could be used for testing out DNSSEC in a security level sufficient for supporting applications. That would at least enable developers to early-adopt DNSSEC on Linux, which would itself be a great achievement in the current status quo.

> On this last point, I think we have a few policy options we can choose
>   from, compromising based on reducing user interactivity and NM changes:
> 
> - Wifi is untrusted, never redirect the received "domain" to the
>    received nameserver IP's, unless the user manually tells us to do so
>    [ policy easy to implement, but requires non-trivial NM changes]
> - If ESSID was known and automatically joined, trust the wifi and make
>    the domain/ns binding [I say this is insecure, because my laptop
>    auto-joins networks it has never been on if the name happens to match,
>    like "linksys" or "PublicWifi", or by active attacks like people
>    setting "redhat.com" on purpose to trick me]
> - If non-open Wifi, assume trust like physical wire. Eg WPA, EAP.
>    [ I am fine with this ]

I added some other NetworkManager developers to see that. We can start a bugzilla with NetworkManager and define the fine-grained policy and configuration options there so that it doesn't get lost in the depths of the mailing list.

Pavel