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 _______________________________________________ dnssec-trigger mailing list dnssec-trigger@NLnetLabs.nl http://open.nlnetlabs.nl/mailman/listinfo/dnssec-trigger