IETF Logo Mail Archive

Re: [Captive-portals] Discovering captive portal API URL via DNS?

Tommy Pauly <tpauly@apple.com> Wed, 04 September 2019 15:52 UTC

Return-Path: <tpauly@apple.com>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C161208B1 for <captive-portals@ietfa.amsl.com>; Wed, 4 Sep 2019 08:52:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 pKvX86ZNxy_t for <captive-portals@ietfa.amsl.com>; Wed, 4 Sep 2019 08:52:41 -0700 (PDT)
Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (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 2A68C12089F for <captive-portals@ietf.org>; Wed, 4 Sep 2019 08:52:41 -0700 (PDT)
Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id x84Fqcue017377; Wed, 4 Sep 2019 08:52:38 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=PaqhJSqM1T43BhwBGso7EfpytqpqKKyS5zes1IDGZvQ=; b=pSG23zgyZI/o+hbUxhYQ44L7QO2S90n2ebuUMMe8kSkwDa+2I/HPxB+HM34u8g331Go+ WueEoHPppNbgxAytuJiCScg2j0YvoKt5Oy6udtMAh0NgYdKUx/i4rzL/n8GZkYEsOr3i mNv4gg29Xf0fvRASE5wbJYCQd8/2W2Sdk/xREBnMCWFwZjF5OCCHVFXml2uP5xQNDWmw XnhVN9sedK3+zsqmNO0jZPkxxAli7thgwW+2yWpeowOL6ReJmvTPpXLntAYetG2RzyYB kNnliqVo7nT1bsvuzTEth+qLVH5o1npLZx30K3NWTf30sJWbZWyjpeDBjQ0Qur4OVY3Y 4A==
Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by nwk-aaemail-lapp01.apple.com with ESMTP id 2uqqu949vb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 04 Sep 2019 08:52:37 -0700
Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PXB00D3UDEPUME0@ma1-mtap-s03.corp.apple.com>; Wed, 04 Sep 2019 08:52:01 -0700 (PDT)
Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PXB00K00DDMJW00@nwk-mmpp-sz13.apple.com>; Wed, 04 Sep 2019 08:52:01 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 4e1e30cd29ff63431456d24db3f05f75
X-Va-E-CD: 1678caf26564d39010d11a2a7fa44003
X-Va-R-CD: 4422c39fb9d4f5c432303b352875d325
X-Va-CD: 0
X-Va-ID: 4a98647f-d9ee-4d52-af24-388676e9529a
X-V-A:
X-V-T-CD: 4e1e30cd29ff63431456d24db3f05f75
X-V-E-CD: 1678caf26564d39010d11a2a7fa44003
X-V-R-CD: 4422c39fb9d4f5c432303b352875d325
X-V-CD: 0
X-V-ID: 98adf587-72bd-428e-96cb-7c448cc419fa
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-09-04_04:,, signatures=0
Received: from [17.234.100.84] by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PXB00K69DEOUK90@nwk-mmpp-sz13.apple.com>; Wed, 04 Sep 2019 08:52:00 -0700 (PDT)
Sender: tpauly@apple.com
Content-type: text/plain; charset="utf-8"
MIME-version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\))
From: Tommy Pauly <tpauly@apple.com>
In-reply-to: <27990.1567606573@dooku.sandelman.ca>
Date: Wed, 04 Sep 2019 08:51:54 -0700
Cc: Lorenzo Colitti <lorenzo@google.com>, captive-portals@ietf.org
Content-transfer-encoding: quoted-printable
Message-id: <5365807C-65CA-4744-A266-8E3CECAA2DA1@apple.com>
References: <CAKD1Yr1mR57OsOzDtjM=7YCV_R6zFF9WPxqA-XrWsuJWv+VTag@mail.gmail.com> <18051.1567582038@dooku.sandelman.ca> <CAKD1Yr0RvYU9TDjiU4Pm9QdVY_Z4XAN74wXcWhMhJ+smQLr_aw@mail.gmail.com> <27990.1567606573@dooku.sandelman.ca>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.3445.104.2)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-04_04:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/OBIfWNxkP-pXPJR0Kle-K3lWPgE>
Subject: Re: [Captive-portals] Discovering captive portal API URL via DNS?
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Sep 2019 15:52:50 -0000

In general, I think that the code on a client system that is intentionally interacting with a Captive Portal (for discovery, etc), will need to use the locally-provisioned DNS. That is probably Do53, but could be DoT/DoH in the future; it would, however, be expected to be under the control of the portal if there is a portal present. Even if a system is strictly using DoT/DoH for other use cases, it needs to have some local exceptions for this kind of "system" traffic. A good example is the ipv4only.arpa lookup on DNS64 networks.

—Tommy

> On Sep 4, 2019, at 7:16 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> 
> Lorenzo Colitti <lorenzo@google.com> wrote:
>    mcr>     that things like DoT/DoH can not be used by the captive portal
>    mcr> client.  (I just want to make the assumption explicit. I'm not
>    mcr> complaining about it)
> 
>> That's not really an assumption - the fact that the captive portal
>> client can't do DoT/DoH is mostly true today, because unless the portal
>> is open, 443 and 853 are likely to be blocked. By and large, DoT / DoH
>> clients probably already know not to attempt them on captive portals.
> 
> Well, a captive portal could leave HTTPS to cloudflare open, the same way
> that they might leave Do53 open to themselves, or to quadX.  That works today
> for some portals.
> 
> And if the portal doesn't let just *any* Do53, but only to known public
> resolvers (which they can even proxy if they want), then they can be sure to
> defeat DNS-VPN mechanisms.
> 
> Some portals today *do* depend upon creating answers for names that aren't
> real.  That fails today if you do DNSSEC validation.  Of course, some still
> depend upon lying about all DNS requests, and but we have agreed that this is
> bad.  
> 
> -- 
> ]               Never tell me the odds!                 | ipv6 mesh networks [ 
> ]   Michael Richardson, Sandelman Software Works        | network architect  [ 
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [ 
> 	
> 
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

v2.23.0 | Report a Bug | By Email