[Dnssec-trigger] [PATCH] Automatic fallback to insecure mode

[Tomas Hozza]

On 30.11.2015 21:41, Paul Wouters wrote:
> On Mon, 30 Nov 2015, Philip Paeps wrote:
>
> >>  To be honest this seems like what we need - if the local resolvers are not
> >>  usable for getting DNSSEC data, use them directly and ignore that they are
> >>  not providing the data.
> >
> > I think this is a really terrible idea.  I'm shocked that this is being considered as a default configuration.
>
> Well, the alternatives are worse :(
>
> Fedora is going to basically be the first player to enable dnssec per
> default. We cannot afford this to turn into another "selinux" where
> at the first sign of trouble, people just disable the whole thing.
>
> So the idea is, enable the extra security but fallback to the current
> insecure status. Then when we gain more confidence, we can bring up the
> security until at some point we can turn this into a "hard fail".
>
> I do agree with you that we need a notification to the user, and a way
> for expert (dns) users to insist on having DNSSEC enabled in a way that
> dnssec-trigger guarantees it. We are trying to build all of this.

Yes, the intentions and motivation is exactly as Paul explained. I should state
that this will not be the default configuration of dnssec-trigger, but rather
the configuration for Fedora Workstation.

> > We should be moving towards more trustworthy DNS.  Deliberately and presumably invisibly turning off DNSSEC validation when it doesn't work is exactly the opposite of what should be done, and what dnssec-trigger does by default: "dear user, your network cannot be trusted; proceed with extreme caution or not at all".
>
> We won't do it invisibly. Some kind of notification will be provided,
> but do note that 90% of users won't really know what to do with that
> popup.

Also Gnome developers don't want to have the dnssec-trigger panel installed
by default. I agree that we can have a better UI for the user. Therefore we
will most probably have to use DBus for exposing some information, which can
be then picked up by NetworkManager and/or Gnome. Ideally the notifications
and user interaction should be native to the Desktop Environment. The possible
change like DBus API should be done just as an opt-in during compilation.

> > I have read your original email in this thread and I wonder why you want to bother with dnssec-trigger at all.  If trustworthiness of the DNS isn't required (or even desirable), you can run unbound as a pure cache without the validator module.
>
> We do want to go there, but early adopters causing a hard fail is not
> going to move anyone forward to universal deployment of dnssec.

Exactly. We want DNSSEC, but while working with and on dnssec-trigger in Fedora
we saw number of situations when DNSSEC simply can not be used due to the network.
So we definitely need dnssec-trigger to do the probing of resolvers and test the
possible fall-back mechanisms before we inform the user that DNSSEC can not be used.

I also think it makes sense to contribute parts we find useful in Fedora back to
dnssec-trigger project. It may not be the default and be turned on / used by default
in upstream, but it may be useful

> > I agree that the present state of affairs (working DNSSEC but barely workable error reporting to application/presentation layer) is not perfect but I strongly feel we should be working on fixing the error reporting rather than working around broken network configurations that interfere with DNSSEC.
>
> It's more complicated than that. For instance, various parts of the OS
> are now independantly trying to deal with hotspot detection, so all of
> this requires coordination between the various OS parts.
>
> > dnssec-trigger is very valuable precisely because it tells the user that the network cannot be trusted.  That's its job.
>
> But the user cannot do much. Usually they have no real alternative
> network, so a popup at most warns them implicitely not to go to banking
> sites or anything important.

I would say this is just one of the things dnssec-trigger does, and from my point
of view not the primary one. I see dnssec-trigger as the tool that tests the current
network to figure out the the right configuration for Unbound so it can do the
name resolution and validation.

The existing means of user interaction in dnssec-trigger are OK if you are enthusiast,
but I'm starting to agree with desktop developers, that for it to be used widely and
by default, the interaction should be native (WRT the desktop environment).

> >  That's the way DNSSEC is supposed to work.  Either you can trust the data returned by the DNS or you need to tell the user that their network cannot be trusted.
>
> Hardfail is just not going to work like that. Look at selinux. Look at
> browser overrides for SSL certificates that are somehow bad. Look at
> the default of allowing mixed https/http content on webpages. If
> browsers didn't do this, they would see their userbase dwindling. The
> situation with SSL and DNS is quite similar.

We just can not deploy Unbound with dnssec-trigger in the OS by default
on every installation and then break the name resolution every time the
network is broken ans DNSSEC can not be used. We have to start gently,
otherwise turning off DNSSEC will be one of the first things everyone
will advise you to do after OS installation.

> > Pretending that everything is fine when you know it isn't is not a 'usable out-of-the-box experience' for regular users.  It's a regression in terms of their security.
>
> Technically speaking, it is not a regression. For the 99.9% of users
> who are now not using dnssec on their own device, going into insecure
> mode is exactly how they are operating right now.

Yes, that is the main idea. In Fedora no default DNS resolver is used after
installation and DNSSEC is not used either. This means it will not be a regression
for users that didn't have dnssec-trigger and Unbound turned on before.

For those who did, the new options that mean "less hardening" will not be
set in their configuration. As I stated before, the defaults in upstream
should stay secure and hard.


I hope that this cleared things a little bit and that you see the reasons
why we want to do such changes.


Regards,
-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
UTC+1 (CET)
Red Hat Inc.                 http://cz.redhat.com