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

[Paul Wouters]

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.

> 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.

> 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.

> 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.

>  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.

> 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.

Paul