[Dnssec-trigger] dnssec-triggerd behaviour when hotspot_signon called

[Pavel Simerda]

----- Original Message -----
> From: "Paul Wouters" <paul at cypherpunks.ca>
> To: "Pavel Simerda" <psimerda at redhat.com>
> Cc: "Tomas Hozza" <thozza at redhat.com>, dnssec-trigger at NLnetLabs.nl
> Sent: Sunday, December 8, 2013 8:23:44 PM
> Subject: Re: [Dnssec-trigger] dnssec-triggerd behaviour when hotspot_signon called
> 
> On Sun, 8 Dec 2013, Pavel Simerda wrote:
> 
> >> But of course, it
> >> would be better not to have to rewrite /etc/resolv.conf.
> >
> > Agreed.
> >
> >> The best solution blocks port 53/unbound from resolution on a new
> >> network until NM has handled the sign-on.
> >
> > I don't think I understand the idea.
> >
> > 1) We need to keep name resolution on the localhost side working.
> 
> No. You cannot. When on a hotspot, there is no valid "name resolution"
> until you have authenticated. Any DNS lookups to applications _should_
> fail, because there is no DNS that is trustworthy.

Common, there are multiple solutions with their pros and con. And so far you have been using the very solution you now consider impossible. So at least we're not talking about a regression, right?

> This is when the user
> sees warnings from IM clients or browsers or email clients saying
> "something wrong with certifiacte" when presented with the ssl variant
> of the hotspot.

If the hotspot has an SSL variant at all. And a transparent SMTP proxy.

> Resolution is better of getting servfails until the
> hotspot has been validated and dns can be trusted.

No. That way you would break people's local network connectivity when a false positive occurs on hotspot detection and they would learn to turn DNSSEC off like they learned with selinux long time ago. Breaking users' networking is not part of our plan.

We can indeed experiment with various solutions and we can develop a "strict mode" that would (partially) block DNS resolution for all tools except a special browser window, but I would rather see it as the next step and I doubt we will be able to make it default.

> > 2) We need to resolve external addresses via hotspot temporarily.
> 
> No. _only_ the addresses required for the hotspot authentication should
> be resolved.

Again, in the first stage, we must not impact functionality, otherwise we'll teach people to turn DNSSEC off.

> > 3) We need to avoid serving those external addresses from the cache when
> > fully connected.
> 
> Not just "when fully connected". Whenever!
> 
> >> From my perspective, the best way would be to teach 'unbound' to either
> >> cache the hotspot-mode results separately or not cache them at all, which
> >> might be even easier. I don't think blocking any unbound communication on
> >> firewall can help.
> >
> >> This can require a hot
> >> spot sign on using some browser window that is isolated from any
> >> running firefox, uses its own resolving - for example using libunbound
> >> in insecure mode that is terminated with the browser window when done.
> >
> > Yes, that would be theoretically possible but unless we really need to do
> > Firefox magic (which we apparently don't), I would rather avoid it. When
> > the only problem is unbound caching during the hotspot registration, then
> > why don't we just solve it there. It's so much easier than any magic and
> > will eventually be more universal.
> 
> I don't think we are agreeing about what the problem is. I am saying it
> is a problem if _any_ application apart from the "hotspot signon" is
> receiveing untrusted DNS that has been specificaly bypassed DNSSEC.

Yes and thank you for reminding me about those requirements that we need to consider when implementing a strict mode. Also, I think we'll need to make larger changes to NetworkManager when implementing the strict mode to synchronize the state of all the tools.

Cheers,

Pavel

> >> This would prevent any and all race conditions to our secure unbound
> >> cache, and would require no resolving. But that "browser window" would
> >> have to not use any libc gethostbyname() or get_addr_info() calls - just
> >> libunbound calls. The system unbound daemon would return SERVFAILs until
> >> its port 53 block is lifted - or it could be put explicitely into "cache
> >> only" mode.
> >
> > Sounds like a solution, but not one I would prefer over simply solving the
> > unbound cache pollution problem. But anyway thanks very much, you helped
> > me to sort my thoughts better. Actually, you can view the "nocache"
> > solution as a simplification of the browser windows solution, as indeed we
> > need to act at the same phases. The only difference is whether we use a
> > separate channel for name resolution, or we handle the caching. Thanks.
> 
> Right.
> 
> Paul
>