From thozza at redhat.com Wed Nov 25 15:23:17 2015 From: thozza at redhat.com (Tomas Hozza) Date: Wed, 25 Nov 2015 16:23:17 +0100 Subject: [Dnssec-trigger] [PATCH] Automatic fallback to insecure mode Message-ID: <5655D265.3020007@redhat.com> 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, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D UTC+2 (CEST) Red Hat Inc. http://cz.redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-auto-insecure-option.patch Type: text/x-patch Size: 4722 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-on-insecure-command-option.patch Type: text/x-patch Size: 3966 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-dnssec-trigger-script-Use-ducktaping-when-restarting.patch Type: text/x-patch Size: 1458 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-dnssec-trigger-script-Silence-the-calls-to-chattr.patch Type: text/x-patch Size: 1175 bytes Desc: not available URL: From thozza at redhat.com Mon Nov 30 09:05:37 2015 From: thozza at redhat.com (Tomas Hozza) Date: Mon, 30 Nov 2015 10:05:37 +0100 Subject: [Dnssec-trigger] [PATCH] Automatic fallback to insecure mode In-Reply-To: <5655D265.3020007@redhat.com> References: <5655D265.3020007@redhat.com> Message-ID: <565C1161.9070403@redhat.com> 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 From paul at nohats.ca Mon Nov 30 13:20:51 2015 From: paul at nohats.ca (Paul Wouters) Date: Mon, 30 Nov 2015 08:20:51 -0500 Subject: [Dnssec-trigger] [PATCH] Automatic fallback to insecure mode In-Reply-To: <565C1161.9070403@redhat.com> References: <5655D265.3020007@redhat.com> <565C1161.9070403@redhat.com> Message-ID: 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. If you contaminate the unbound cache and/or force cache clears, then I consider that solution unworkable for me personally. Paul Sent from my iPhone > On Nov 30, 2015, at 04:05, Tomas Hozza 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 From thozza at redhat.com Mon Nov 30 13:55:40 2015 From: thozza at redhat.com (Tomas Hozza) Date: Mon, 30 Nov 2015 14:55:40 +0100 Subject: [Dnssec-trigger] [PATCH] Automatic fallback to insecure mode In-Reply-To: References: <5655D265.3020007@redhat.com> <565C1161.9070403@redhat.com> Message-ID: <565C555C.2030306@redhat.com> 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 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 From paul at nohats.ca Mon Nov 30 14:04:58 2015 From: paul at nohats.ca (Paul Wouters) Date: Mon, 30 Nov 2015 09:04:58 -0500 (EST) Subject: [Dnssec-trigger] [PATCH] Automatic fallback to insecure mode In-Reply-To: <565C555C.2030306@redhat.com> References: <5655D265.3020007@redhat.com> <565C1161.9070403@redhat.com> <565C555C.2030306@redhat.com> Message-ID: On Mon, 30 Nov 2015, Tomas Hozza 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. Well, it makes the cache untrusted and contaminated. >> 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. But there is an option to disable that, on my request, because as I explained, 1) starting from a fresh cache increases the risk of cache poisoning, and 2) it leaves a very veriably fingerprint when my combination of software starts doing DNS queries. So I use that option to disable the cache flush. > 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. I understand it works in the default deploymentment planned. > 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. This behaviour plus the option to disable cache flush should not be allowed to be active at the same time. It leads to possible fraudulent data in the unbound cache when the cache is expected to be trustworthy. Paul From thozza at redhat.com Mon Nov 30 15:18:58 2015 From: thozza at redhat.com (Tomas Hozza) Date: Mon, 30 Nov 2015 16:18:58 +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> Message-ID: <565C68E2.4010303@redhat.com> On 30.11.2015 15:04, Paul Wouters wrote: > On Mon, 30 Nov 2015, Tomas Hozza 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. > > Well, it makes the cache untrusted and contaminated. I don't think the cache is trustworthy, but only the validated responses are. This will be achieved, since no responses will be validated in this scenario and no AD flag will be set. > >> 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. > > But there is an option to disable that, on my request, because as I > explained, 1) starting from a fresh cache increases the risk of cache > poisoning, and 2) it leaves a very veriably fingerprint when my > combination of software starts doing DNS queries. So I use that option > to disable the cache flush. The cache is flushed in that case too, but only the negative answers. > > 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. > > I understand it works in the default deploymentment planned. > > > 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. > > This behaviour plus the option to disable cache flush should not be > allowed to be active at the same time. It leads to possible fraudulent > data in the unbound cache when the cache is expected to be trustworthy. Sure, that seems reasonable. > Paul Tomas -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D UTC+1 (CET) Red Hat Inc. http://cz.redhat.com From philip at trouble.is Mon Nov 30 16:35:59 2015 From: philip at trouble.is (Philip Paeps) Date: Mon, 30 Nov 2015 22:05:59 +0530 Subject: [Dnssec-trigger] [PATCH] Automatic fallback to insecure mode In-Reply-To: <565C555C.2030306@redhat.com> References: <5655D265.3020007@redhat.com> <565C1161.9070403@redhat.com> <565C555C.2030306@redhat.com> Message-ID: <1C9841EE-8BA8-4E20-A71E-1831A75D23D3@trouble.is> On 2015-11-30 19:25:40 (+0530), Tomas Hozza wrote: > 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. That is my understanding too. I feel this is a good thing though. > 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. 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". I hadn't even considered the cache poisoning issue Paul points out. That just makes a bad solution seem even worse. > 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. 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. 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. dnssec-trigger is very valuable precisely because it tells the user that the network cannot be trusted. That's its job. 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. 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. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information From paul at nohats.ca Mon Nov 30 20:41:34 2015 From: paul at nohats.ca (Paul Wouters) Date: Mon, 30 Nov 2015 15:41:34 -0500 (EST) Subject: [Dnssec-trigger] [PATCH] Automatic fallback to insecure mode In-Reply-To: <1C9841EE-8BA8-4E20-A71E-1831A75D23D3@trouble.is> References: <5655D265.3020007@redhat.com> <565C1161.9070403@redhat.com> <565C555C.2030306@redhat.com> <1C9841EE-8BA8-4E20-A71E-1831A75D23D3@trouble.is> Message-ID: 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