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

"Martin Thomson" <mt@lowentropy.net> Fri, 15 March 2019 11:26 UTC

Return-Path: <mt@lowentropy.net>
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 D9C3E127918 for <doh@ietfa.amsl.com>; Fri, 15 Mar 2019 04:26:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=m0RtsXQt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=y2z8RMZy
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 IkDNyPvRtPWM for <doh@ietfa.amsl.com>; Fri, 15 Mar 2019 04:26:10 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3385B131227 for <doh@ietf.org>; Fri, 15 Mar 2019 04:26:10 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E8E5121F93; Fri, 15 Mar 2019 07:26:08 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Fri, 15 Mar 2019 07:26:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=Ve3mjbcmOvS/cVcNQxF0fcq6JWU2 Yb9m9UD97tRDNHI=; b=m0RtsXQtdSrMwbZ0tg8E1JdWl3BnUlbeHnQ9nUZWxR+k xhypaa29lFN5WrL8h5k3w9e4dtN7Tc2DYGO3ME1xv6N5fASQIYFoOd1ipCFhnxTD vDAsbEsKB294pfnqyZaDdy4BiZLfRyXonnwjtPgSJHw03lXWmZxYUCpiXzkLtJ8I 8o0ZOxkzia05kepw+6T7MxTf5bEcQwjZBVmHwDFnPk3UkyLdKutWJ0ZGTvKHYEQd rDyens1gTW9/sNA2nX8/OKRClOZg1w/IazaTC/+kYpC1Gira0VrdGFtawIcNF/bt kJyElx7lR4BAFSA+zNCNGWHAFWYA5VuTcVqPBHWq8A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=Ve3mjb cmOvS/cVcNQxF0fcq6JWU2Yb9m9UD97tRDNHI=; b=y2z8RMZywA0RDgVnvbQTey 8JSGhpw1P2u+UPyMo9r8hWtSa4V5EcpgSQicSAy9Tm0Je+SdWnQc3pCUrgmijl3c /MFcQC1m/GyF/2FgAdk74hkm7IAHzq9+cNip3txkhE85e+GGwNRSc2MwbYSohDBY YIV8u0/LlS4yl1akLCFCfge+8YMYJmAsTC9vu/VKk3xWM+hb/R4ZF4qOyG5vMxbW ueWhSzooIklWGm1qGpy042Z+zFrEOxQjGtoiJOe0uQDGo1Ks95S6zrrWHAolCKRk 50i2ZKFDHwIvDt8BxsUyRPTICi+QyDaxt/F1HX2ukvurVuu5FIlbKCwyO91CF81A ==
X-ME-Sender: <xms:0IuLXIE0ZdSmsmDXluGMNy8OzHzOhOH92GbID4X-RZguUZRXdWz_-Q>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrheehgddvkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofi gvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:0IuLXFk2VEKHpaniVy4q0AdFTy4ICIN8JbNoO3_NePJp8gP63HWTQQ> <xmx:0IuLXNIGZvBFXbOWVdhe9ZybThE2GppaE7s1Xj4WTFJ-ZuXLGBBkoQ> <xmx:0IuLXOacKHpeYeZesZr_lXeRZmJokT5wJj6B7CxPTEoCFehS1lLQRg> <xmx:0IuLXHQB8tMP8fntgPQey_2T9o535rCJXSG9VAgFXaYv8pNOZJEcWQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 34F157C32E; Fri, 15 Mar 2019 07:26:08 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.5-976-g376b1f3-fmstable-20190314v3
Mime-Version: 1.0
X-Me-Personality: 92534000
Message-Id: <0c060e21-c1a4-4768-9fad-27ac85da391f@www.fastmail.com>
In-Reply-To: <9B23961D-8D05-462C-A444-0139B354F171@rfc1035.com>
References: <A0E89D03-9D2D-462F-88F4-11824AC9A523@rfc1035.com> <0fce90e8-38ef-4503-8e52-0ef8c8d87f64@www.fastmail.com> <9B23961D-8D05-462C-A444-0139B354F171@rfc1035.com>
Date: Fri, 15 Mar 2019 07:26:10 -0400
From: Martin Thomson <mt@lowentropy.net>
To: Jim Reid <jim@rfc1035.com>
Cc: doh@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/OkWXnPLceZTgC1F67M0jueCMERk>
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 11:26:12 -0000

On Fri, Mar 15, 2019, at 18:39, 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. 

If the OS catches the captive portal, everything works nicely once the captive portal is dealt with.  If the captive portal manages to evade detection...

The app might blithely continue.  If the resolver is now blocked by the captive portal (remember, we already have an IP address) then name resolution fails the next time it is needed.

The app that Daniel talks about is more sophisticated.  It attempts to detect the new network and then tries to restart its bootstrapping process.  This is highly unreliable both in detecting the move and in detecting the captive portal (after all the OS missed it too).  So the sophisticated app often ends up looking like the dumb one. 

But this isn't that unique.  It's not just name resolution that fails in this case.  We're back that the "you connected to a broken network" mess I described in my original mail.

The only real take-away then is that evading captive portal detection produces a terrible user experience.