[Doh] Captive portals (was Re: suggested slides for IETF 104 on draft-reid-doh-operator)

["Martin Thomson" <[e-mail]>]

Thanks for sharing the slides Jim,

(As an aside, the parallels between your summary of the draft and draft-mm-wg-effect-encrypt are striking.)

There are lots of *things* on your list, but maybe it would help to look at a few in more detail to see what they teach us.  I happen to chair a working group that is tasked with improving the captive portal situation, so I thought I'd start there because it's first on your list too.

The first thing I observe is that the story could be different depending on where the remote resolver is configured.  In particular, whether you consider the configuration of an remote, encrypted resolver to be system-wide or per-application.

Captive portal detection is typically done at a system level, and so the system-wide configuration would seem to be most relevant to this particular issue.  That is, unless the network manages to successfully evade the various captive portal detection mechanisms in the hopes that they can somehow present information in the browser, which I'll get back to.

As I've learned, operating systems typically use very different network configuration during the captive portal detection phase, and most won't be applying encrypted DNS policies until they have first validated the network is "usable".  So I would expect that even if the operating system is configured to use an encrypted DNS service other than the one the network provides, it would still use the network-provided service while it is bootstrapping.  For instance, I understand that Android uses the network resolver to discover the IP address of its DoT/DoH resolver (Ben can probably clarify/correct me here).

If the network decides to evade captive portal detection, then it is playing roulette.  Most applications now use authenticated connections to services, and so do many websites.  A DNS redirection is no more effective in these circumstances than a port 80 interception[1].  The application detects the "attack" and throws up errors.  That can lead to the operating system concluding that the network is broken if applications report these errors.  If you are lucky and it is a web browser that first makes a connection and that connection is to a site without HSTS, then the network gets a chance to show a web page.  I shouldn't need to quote stats on app vs. browser usage and proportion of HTTPS on the web to make it clear that this playing this game has increasingly bad prospects.

If this is a per-application configuration, then only those applications that are configured to use remote, encrypted resolvers are affected.  They fail to get the modified DNS results, but all the other problems still exist.

That makes me conclude that captive portals aren't any worse off as a result of operating systems or applications choosing to configure their own encrypted resolver service.  Given that using DNS for captive portals is worse than alternative methods[1], I'd suggest that we not concern ourselves with this particular problem.

Cheers,
Martin

[1] Spoofing DNS results for captive portals poisons the cache, which makes DNS rewriting a bad choice for this use case.  This is - in part - why most captive portals intercept TCP on port 80 and spoof an HTTP 302 instead.  And if you consider DNSSEC-validating endpoints, that would be another reason not to spoof DNS... if those existed in any significant numbers.


On Fri, Mar 15, 2019, at 03:39, Jim Reid wrote:
> Here’s what I plan to present at the WG. Please comment on the list if 
> you have questions or suggestions.