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

Tommy Pauly <tpauly@apple.com> Mon, 18 March 2019 16:57 UTC

Return-Path: <tpauly@apple.com>
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 ABC94130E94; Mon, 18 Mar 2019 09:57:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 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] 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 Rp4S1_XYq73e; Mon, 18 Mar 2019 09:57:37 -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 8A6D7131117; Mon, 18 Mar 2019 09:57:33 -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 x2IGpiga030365; Mon, 18 Mar 2019 09:57:32 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-transfer-encoding : content-type : sender : subject : from : in-reply-to : date : cc : message-id : references : to; s=20180706; bh=VcIMMA/gkKbDl6K4vkGIo1bmG98KltRzU7VBdxycJ84=; b=fJKsd4xWSvdDuUF0siyh/JkO8C/wEZdnP2pkTPqX3xkTra7rwiuwyCx71DM+Pl8w5T5o ON2xb+9kdC3f2yS6mQcx2JZyu9BV+/rWTevBy2hZUBulZQEjvaMAQHM8q4iqCg27HNUc OIQvOWbLDb/BcnXsED4jUairPBlnWSryjfoN4qmeWzzxd3j0JI4qrf/RNjoS49+zBvGL RK1HnZNuz9noW/j4Bq6ExKt9AMyn4TcabJ4h6z/7TWMMPr2+u2cPz0YGDCZqCcDl0af3 kpMiSkO6Cfmlwk9m07CPxogwRHcIg0N4SRKjIIJapgzDKIKNOWDEHLXYIrFPGMnrshsz AQ==
Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) by nwk-aaemail-lapp01.apple.com with ESMTP id 2r90363kwd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 18 Mar 2019 09:57:32 -0700
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; CHARSET="US-ASCII"
Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0POK00B0DN3W4A30@mr2-mtap-s02.rno.apple.com>; Mon, 18 Mar 2019 09:57:32 -0700 (PDT)
Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0POK00500N3F7100@nwk-mmpp-sz12.apple.com>; Mon, 18 Mar 2019 09:57:32 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 296c58069bb7033e87817fa69e9297e4
X-Va-E-CD: f36d24f4166a51085dfe864b34fd6507
X-Va-R-CD: d217ec155e4277cc4af3bc5201f79542
X-Va-CD: 0
X-Va-ID: 50c831c3-761c-46fe-b081-ba67aef553d7
X-V-A:
X-V-T-CD: 148aee0f1043947b2dd199222e4ab243
X-V-E-CD: f36d24f4166a51085dfe864b34fd6507
X-V-R-CD: d217ec155e4277cc4af3bc5201f79542
X-V-CD: 0
X-V-ID: ed123c8c-d74f-4b04-8610-c73a31089f7b
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-03-18_11:,, signatures=0
Received: from [17.192.171.189] (unknown [17.192.171.189]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0POK00KZ0N1BA000@nwk-mmpp-sz12.apple.com>; Mon, 18 Mar 2019 09:55:59 -0700 (PDT)
Sender: tpauly@apple.com
From: Tommy Pauly <tpauly@apple.com>
In-reply-to: <ffe718fd-c7dc-d004-dfeb-4769780f5d50@gmail.com>
Date: Mon, 18 Mar 2019 09:55:56 -0700
Cc: doh@ietf.org, captive-portals@ietf.org
Message-id: <BA2F03C4-B78C-4085-880F-C9086482377E@apple.com>
References: <A0E89D03-9D2D-462F-88F4-11824AC9A523@rfc1035.com> <0fce90e8-38ef-4503-8e52-0ef8c8d87f64@www.fastmail.com> <9B23961D-8D05-462C-A444-0139B354F171@rfc1035.com> <0c060e21-c1a4-4768-9fad-27ac85da391f@www.fastmail.com> <ffe718fd-c7dc-d004-dfeb-4769780f5d50@gmail.com>
To: Thomas Peterson <hidinginthebbc@gmail.com>
X-Mailer: Apple Mail (2.3445.104.2)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-18_11:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/Cr4pfLih8U0h6j6bTpczdRiFntE>
Subject: Re: [Doh] [Captive-portals] 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: Mon, 18 Mar 2019 16:57:40 -0000


> On Mar 15, 2019, at 5:22 AM, Thomas Peterson <hidinginthebbc@gmail.com> wrote:
> 
> (to those exclusively on the captive-portals list, this email follows on a discussion around a presentation discussing implications of DNS over HTTP in networks where captive portals are present)
> 
> On 15/03/2019 11:26, Martin Thomson wrote:
>> 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...
> 
> As there are numerous folk from browser and OS vendors within this mailing list who implement capture portal detection, would there benefit in authoring an informational document covering capture portal detection methods in the absence of a network's DHCP service not implementing RFC 7710? Such a document may help describe common methods to inform implementers and minimise detection evading capture portals. It may be better placed in the capport WG instead of doh.

Agreed that CAPPORT is a good place for this discussion.

As far as providing a document to describe OS-vendor-specific mitigations, I'm not sure if the benefit would be that large. It may be useful as an appendix in our Captive Portal Architecture document? The problem is that captive portals that want to whitelist OS probes for portals always can some way or another. Captive portals that do want to play nice don't whitelist these probes, and the detection generally works fine.

Thanks,
Tommy
 
> 
> Regards
> 
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals