From thozza at redhat.com Tue Dec 1 12:26:49 2015 From: thozza at redhat.com (Tomas Hozza) Date: Tue, 1 Dec 2015 13:26:49 +0100 Subject: [Dnssec-trigger] [PATCH] Automatic fallback to insecure mode In-Reply-To: References: <5655D265.3020007@redhat.com> <565C1161.9070403@redhat.com> <565C555C.2030306@redhat.com> <1C9841EE-8BA8-4E20-A71E-1831A75D23D3@trouble.is> Message-ID: <565D9209.5080202@redhat.com> 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. Yes, the intentions and motivation is exactly as Paul explained. I should state that this will not be the default configuration of dnssec-trigger, but rather the configuration for Fedora Workstation. > > 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. Also Gnome developers don't want to have the dnssec-trigger panel installed by default. I agree that we can have a better UI for the user. Therefore we will most probably have to use DBus for exposing some information, which can be then picked up by NetworkManager and/or Gnome. Ideally the notifications and user interaction should be native to the Desktop Environment. The possible change like DBus API should be done just as an opt-in during compilation. > > 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 also think it makes sense to contribute parts we find useful in Fedora back to dnssec-trigger project. It may not be the default and be turned on / used by default in upstream, but it may be useful > > 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. I would say this is just one of the things dnssec-trigger does, and from my point of view not the primary one. I see dnssec-trigger as the tool that tests the current network to figure out the the right configuration for Unbound so it can do the name resolution and validation. 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). > > 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. 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. > > 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. Yes, that is the main idea. In Fedora no default DNS resolver is used after installation and DNSSEC is not used either. This means it will not be a regression for users that didn't have dnssec-trigger and Unbound turned on before. For those who did, the new options that mean "less hardening" will not be set in their configuration. As I stated before, the defaults in upstream should stay secure and hard. I hope that this cleared things a little bit and that you see the reasons why we want to do such changes. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D UTC+1 (CET) Red Hat Inc. http://cz.redhat.com From pspacek at redhat.com Tue Dec 1 12:34:07 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 1 Dec 2015 13:34:07 +0100 Subject: [Dnssec-trigger] [PATCH] Automatic fallback to insecure mode In-Reply-To: References: <5655D265.3020007@redhat.com> <565C1161.9070403@redhat.com> <565C555C.2030306@redhat.com> <1C9841EE-8BA8-4E20-A71E-1831A75D23D3@trouble.is> Message-ID: <565D93BF.6000507@redhat.com> 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 From philip at trouble.is Tue Dec 1 12:48:08 2015 From: philip at trouble.is (Philip Paeps) Date: Tue, 01 Dec 2015 18:18:08 +0530 Subject: [Dnssec-trigger] [PATCH] Automatic fallback to insecure mode In-Reply-To: <565D9209.5080202@redhat.com> References: <5655D265.3020007@redhat.com> <565C1161.9070403@redhat.com> <565C555C.2030306@redhat.com> <1C9841EE-8BA8-4E20-A71E-1831A75D23D3@trouble.is> <565D9209.5080202@redhat.com> Message-ID: On 2015-12-01 17:56:49 (+0530), Tomas Hozza 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 From pspacek at redhat.com Tue Dec 8 10:23:17 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 8 Dec 2015 11:23:17 +0100 Subject: [Dnssec-trigger] [rfc-dist] RFC 7710 on Captive-Portal Identification Using DHCP or Router Advertisements (RAs) References: dnssec-trigger@nlnetlabs.nl Message-ID: <5666AF95.4060903@redhat.com> Hello, this might be interesting for dnssec-trigger. Basically it announces URI of the captive portal so the client knows that captive portal detection is pointless and captive portal page can be opened right away, without delays. Security considerations are described in the RFC. Petr^2 Spacek -------- Forwarded Message -------- Subject: [rfc-dist] RFC 7710 on Captive-Portal Identification Using DHCP or Router Advertisements (RAs) Date: Mon, 7 Dec 2015 16:38:26 -0800 (PST) From: rfc-editor at rfc-editor.org To: ietf-announce at ietf.org, rfc-dist at rfc-editor.org CC: drafts-update-ref at iana.org, rfc-editor at rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 7710 Title: Captive-Portal Identification Using DHCP or Router Advertisements (RAs) Author: W. Kumari, O. Gudmundsson, P. Ebersman, S. Sheng Status: Standards Track Stream: IETF Date: December 2015 Mailbox: warren at kumari.net, olafur at cloudflare.com, ebersman-ietf at dragon.net, steve.sheng at icann.org Pages: 8 Characters: 16352 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-wkumari-dhc-capport-16.txt URL: https://www.rfc-editor.org/info/rfc7710 DOI: http://dx.doi.org/10.17487/RFC7710 In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive-portal mode. This highly restricts what the customer can do until the customer has authenticated. This document describes a DHCP option (and a Router Advertisement (RA) extension) to inform clients that they are behind some sort of captive-portal device and that they will need to authenticate to get Internet access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be used in larger solutions. The method of authenticating to and interacting with the captive portal is out of scope for this document. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor at rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ rfc-dist mailing list rfc-dist at rfc-editor.org https://www.rfc-editor.org/mailman/listinfo/rfc-dist http://www.rfc-editor.org From wouter at nlnetlabs.nl Tue Dec 8 15:36:23 2015 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Tue, 08 Dec 2015 16:36:23 +0100 Subject: [Dnssec-trigger] Dnssec trigger 0.13 for OSX 10.11 (El Capitan) Message-ID: <5666F8F7.3080306@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, OSX 10.11 turned out to not work with dnssec-trigger 0.12. If you want to use dnssec-trigger on OSX 10.11 here is a snapshot of 0.13 that you can use: http://www.nlnetlabs.nl/~wouter/dnssectrigger-0.13_20151208.dmg sha1 636c7e33e9cad57c29b7d8222fc9d936145eb6d5 sha256 fa1c70acd7edc14f2c68e9154e32b9024e1cbeac1d0e17a3a4a90c1102320112 (hashes for the dmg) - - OSX installer changes for OSX 10.11 - - OSX install is in /usr/local - - OSX install includes static openssl, this version 1.0.2e. - - Update OSX resolvehook to flush dns caches for new OSX release with "discoveryutil udnsflushcaches" and "discoveryutil mdnsflushcache". Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWZvj3AAoJEJ9vHC1+BF+NjkoP/38zF5mbZMIrNEhq6xHNc/ZZ IqJVXGuzvexIV9l6zxhppObYkSmhvCv5bqT7v7b7X7TfJQeeCdm4UnRnGWyP00Db eRWf4dAdkYv3Xl3r2u70hhu3eDp9Ov+pPRga5zwd/fej1L4p3a1iRBvIdEr4+hhY T7wtgG3n7SrEwLpzv1WxtTEjC/iKZohImkED2g0WKH50WkXylBoEOk4bJpwZtD2/ iDdzqdAkW2x9wppwV0UUzmyPD5MEOOBH2TvkwT6owS6Q8PoEW/jZyUvx4DUMOU1t fB+zBpPh+JrK9+SX2i0+Oc7RcODubvHhP+Quv7lLbHvNMdCqXK/XncOc1AZZHr/x sy3iNvv9QoRAywAbzuZx58yDRVZn1Rm93L2iVqAK+vCJau/28GqNLVYI35iymZyr 2ig04lVG92JKt5h8vuYxjEwoCi0g5YFsStXh6KlZdChjU1JgzLE16zeY5wM8kjD9 7t8w/zKHqRe0/HXq/Vsi7qJhnmr/Ml/ZkDaxFDKvmeBOdepQdFvCVW5mzuDjCi7D DiD5tWp8/P1EhdDPhl4pCAYWU4gnYPVVgFoomUhsayWyVO69g7A52MbJJPp88cji Ax3hd9GRbJcw5K/JCX+t8MUY8vGq3zGznSEnqPa1kUnr3cW7sysKXapQ/E9V/cal tKdZGJeWRraOr0lUxfp+ =Ua6S -----END PGP SIGNATURE-----