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

Mon Nov 30 13:55:40 UTC 2015

On 30.11.2015 14:20, Paul Wouters wrote:
> Did you mean turning of validation instead of hardening? Hardening strips things out of additional data, I don't think that's what you want.

AFAIK the only real way to turn off the validation in Unbound is not to use validator module. This can not be done during runtime.

There are multiple types of hardening and the one I'm talking about does not strip anything from any section of the answer:

"Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes bogus. If turned off, and no DNSSEC data is received (or the DNSKEY
data fails to validate), then the zone is made insecure, this behaves like there is no trust anchor. You could turn this off if you are  sometimes  behind
an intrusive firewall (of some sort) that removes DNSSEC data from packets, or a zone changes from signed to unsigned to badly signed often. If turned off
you run the risk of a downgrade attack that disables security for a zone. Default is on."

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.

> If you contaminate the unbound cache and/or force cache clears, then I consider that solution unworkable for me personally.

We flush the cache on every network configuration change. Switch to insecure mode can happen only after network configuration change. In such situation there is nothing to contaminate, because the cache is flushed. Also after the switch to/from insecure mode the cache will have to be flushed.

Please be more specific about why this would not work for you. We will have to come up with some sensible behavior and defaults (and flushing cache is one of them IMO), because we want to move from the solution that worked for handful of hackers that knew what is happening, to the solution that will be used by default and has to be usable out-of-the-box for regular users.

Tomas

> Paul
>
> Sent from my iPhone
>
> > On Nov 30, 2015, at 04:05, Tomas Hozza <thozza at redhat.com> wrote:
> >
> >> On 25.11.2015 16:23, Tomas Hozza wrote:
> >> Hi.
> >>
> >> In Fedora we had a discussions with GNOME and NetworkManager
> >> developers about how to seamlessly integrate dnssec-trigger
> >> and Unbound by default to the Workstation Product of Fedora.
> >>
> >> The bottom line was that we should not use the panel applet
> >> and rather do some better integration with NM and let GNOME
> >> do some work.
> >>
> >> Also some important decisions had been made, like automatic
> >> switch to insecure mode when all attempts to use DNSSEC have
> >> failed. This is mainly to NOT to break user experience and
> >> rather fall back to the current state in which DNSSEC validation
> >> is not done by default in Fedora.
> >>
> >> Not having panel installed is the easy part, we split it into
> >> separate sub-package which is not installed by default.
> >>
> >> NM already implements the Captive Portal detection, GNOME
> >> checks the connectivity state in NM and is able to
> >> launch a browser window. Therefore we disabled the Captive
> >> Portal detection in dnssec-trigger and also disabled the
> >> login-action when installed on Workstation. Now such situation
> >> need to be handled properly anyway in dnssec-trigger. By
> >> properly I mean that for the time of hotspot login dnssec-trigger
> >> should be switched to the hotspot signon mode. NM devels
> >> will add the notifications on Connectivity state changes into
> >> nm-dispatcher. This would allow us to call dnssec-trigger-control
> >> from the dnssec-trigger Python script we use and switch
> >> dnssec-trigger to the hotspot signon mode. The switch back
> >> should be done also by calling dnssec-trigger-control to
> >> reprobe. However my ideas how to do it may change once I start
> >> testing it.
> >>
> >> Some parts are still missing, but we are working on it.
> >> We are restarting the effort to have Unbound and dnssec-trigger
> >> installed and used by default from next Fedora (24), so you'll
> >> see more emails from us :)
> >>
> >> I started by implementing the automatic switch to insecure mode.
> >>
> >> I added two new options:
> >> 1. auto-insecure - which takes yes/no and makes dnssec-trigger to
> >> switch to insecure mode in case DNSSEC can not be used on the
> >> network. This is done without any user interaction.
> >>
> >> 2. on-insecure-command - which takes string that will be run as
> >> a command on switch to insecure mode. This seemed to be handy for
> >> the future e.g. for triggering a notification to the user.
> >>
> >> I'm also attaching two changes for dnssec-trigger-script,
> >> which are more of a cosmetic changes to not scare users with
> >> unnecessary warnings and errors.
> >>
> >> Regards,
> >>
> >>
> >>
> >> _______________________________________________
> >> dnssec-trigger mailing list
> >> dnssec-trigger at NLnetLabs.nl
> >> http://open.nlnetlabs.nl/mailman/listinfo/dnssec-trigger
> >
> > Hi.
> >
> > In Fedora we are currently discussing a different approach for
> > insecure mode, which would leave the localhost address in resolv.conf,
> > and rather set 'harden-dnssec-stripped' to 'no' in Unbound.
> >
> > Please wait with applying the changes I sent.
> >
> > Thanks ans sorry for the complications.
> >
> > Regards,
> > --
> > Tomas Hozza
> > Software Engineer - EMEA ENG Developer Experience
> >
> > PGP: 1D9F3C2D
> > UTC+1 (CET)
> > Red Hat Inc.                 http://cz.redhat.com
> > _______________________________________________
> > dnssec-trigger mailing list
> > dnssec-trigger at NLnetLabs.nl
> > http://open.nlnetlabs.nl/mailman/listinfo/dnssec-trigger

-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

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