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

[Philip Paeps]

On 2015-12-01 17:56:49 (+0530), Tomas Hozza <thozza at redhat.com> wrote:
> On 30.11.2015 21:41, Paul Wouters wrote:
>> On Mon, 30 Nov 2015, Philip Paeps wrote:
>>> 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 am not opposed to the "softfail" option for broken networks (provided
that it doesn't poison the cache and worsen the security situation when
moving to an unbroken network).  I do however feel the user should be
told very clearly that the network they are on is broken and that they
should shout at someone about it.

It sounds like we're agreeing though. :)

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

It would be a huge step forward if the desktop environment would tell
the user that something is terribly wrong with their network and maybe
keep nagging them about it in a discreet way.

If probe fails, pop up a warning -- similar to the one we have now --
that the network is broken.  Default to "yes, I get it, just let me go
online please".  Bonus points for an option to disconnect and perhaps a
checkbox "disconnect me every time this happens".

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

This is starting to remind me of the discussions about not turning on
IPv6 by default in the early 2000s which contributed in no small way to
the slow adoption of IPv6.  It would be nice not to make the same
mistakes again.

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

Sure.  But the dnssec-trigger panel icon has a reminder that something
is wrong and -- hopefully -- makes the user more cautious.

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

I think we're mostly in agreement.  I was worried that you intended to
simply try DNSSEC and if it fails, silently turn it off.  I'm okay with
turning it off (by default -- with the option not to!) if it doesn't
work, provided you tell the user about it.  And that you don't poison
the cache when moving from an insecure network to a secure one later.

Philip

-- 
Philip Paeps
Senior Reality Engineer
Ministry of Information