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

Daniel Stenberg <daniel@haxx.se> Fri, 15 March 2019 08:12 UTC

Return-Path: <daniel@haxx.se>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873061311E6 for <doh@ietfa.amsl.com>; Fri, 15 Mar 2019 01:12:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NSwxnlOL6lQ for <doh@ietfa.amsl.com>; Fri, 15 Mar 2019 01:11:58 -0700 (PDT)
Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E6101311DC for <doh@ietf.org>; Fri, 15 Mar 2019 01:11:58 -0700 (PDT)
Received: from giant.haxx.se (mail [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id x2F8Brd1001512 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 15 Mar 2019 09:11:53 +0100
Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id x2F8BqxY001502; Fri, 15 Mar 2019 09:11:52 +0100
X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs
Date: Fri, 15 Mar 2019 09:11:52 +0100 (CET)
From: Daniel Stenberg <daniel@haxx.se>
X-X-Sender: dast@giant.haxx.se
To: Jim Reid <jim@rfc1035.com>
cc: Martin Thomson <mt@lowentropy.net>, doh@ietf.org
In-Reply-To: <9B23961D-8D05-462C-A444-0139B354F171@rfc1035.com>
Message-ID: <alpine.DEB.2.20.1903150903480.5797@tvnag.unkk.fr>
References: <A0E89D03-9D2D-462F-88F4-11824AC9A523@rfc1035.com> <0fce90e8-38ef-4503-8e52-0ef8c8d87f64@www.fastmail.com> <9B23961D-8D05-462C-A444-0139B354F171@rfc1035.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
X-fromdanielhimself: yes
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="1129329158-732140084-1552637513=:5797"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/bKHZD7A0upGXvvlJHVE4-40YksU>
Subject: Re: [Doh] Captive portals (was Re: suggested slides for IETF 104 on draft-reid-doh-operator)
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Mar 2019 08:12:01 -0000

On Fri, 15 Mar 2019, Jim Reid wrote:

> Suppose a DoH client has already bootstrapped itself and knows the address 
> of its chosen DoH server. The device moves to a new net that has a captive 
> portal. Will the device try to speak DoH to that server’s address directly 
> instead of doing the captive portal dance?

Then we enter application specific territory. A hypothetical browser might for 
example first verify that it is "captive portal-less" before it activates DoH, 
and it might also feature a config entry that skips that waiting period (a 
wait that is annoying when you restart your browser and have N tabs you'd like 
to reload at once etc).

Yes, validating local resolvers (and others) have the same problem. Captive 
portals in general are a world of pain.

> Likewise, what happens what a DoH client is configured to only use DoH and 
> therefore never interacts with the network’s or captive portal’s por 53 
> resolver?

A browser set to *only* use DoH and never "native" will effectively be locked 
out from the network when it finds itself in a captive portal. (There's at 
least one Firefox bug on this.) Which proves that all pieces work as intended!

In those cases, some users have been known to fire up a *separate* browser to 
resolve the captive situation as then the DoH-using browser can come back to 
the living.

-- 

  / daniel.haxx.se