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

[Petr Spacek]

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

Thank you for summarizing this, Paul.

Once again, I would like to reiterate the point that *this is a temporary
measure*. It allows us to put dnssec-trigger and Unbound as validator
literally everywhere, into every network, without breaking 60 % of clients in
some way [1, page 22, table 11].

Imagine that we were DNSSEC fundamentalists and decided to break 60 % clients
in some way. That would cause a huge backlash against DNSSEC validation on end
clients.

[1]
http://www.nlnetlabs.nl/downloads/publications/os3-2015-rp2-xavier-torrent-gorjon.pdf

-- 
Petr Spacek  @  Red Hat