Re: [Captive-portals] Fixing RFC 7710

Warren Kumari <warren@kumari.net> Fri, 02 March 2018 22:52 UTC

Return-Path: <warren@kumari.net>
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 EFAB2126B6E for <captive-portals@ietfa.amsl.com>; Fri, 2 Mar 2018 14:52:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=kumari-net.20150623.gappssmtp.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 a5OKIEmiB9sN for <captive-portals@ietfa.amsl.com>; Fri, 2 Mar 2018 14:52:45 -0800 (PST)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2A811250B8 for <captive-portals@ietf.org>; Fri, 2 Mar 2018 14:52:44 -0800 (PST)
Received: by mail-wm0-x236.google.com with SMTP id w128so5910588wmw.0 for <captive-portals@ietf.org>; Fri, 02 Mar 2018 14:52:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Nvh7RACo42xwTP6PiFcKgqzxCoNF4kiCpmi1UJgvq1U=; b=1A3Mdjd90x9wrC1bKJVERCubM1Y3L4Taex9njjAKikLDypLJBFFmEe9z4MvLeU4uKa doS63ru4k6btbpN/FULyjGeVFnweJ3AIzOAFDJX5QoWSB3MMp9tgAjs+fDJy8DSl4jeM twKbmPW9JKmPDp8h4R3pjwlJaMr85aeYTD8qMc73w2TKbYeRfmFoFkRNFl0ZNAMOgivj kwQgmlLEgoDJrIkyiv44qv7CTw5pI0/w56VlaalJtbXrNqUE67YvRk9O6UkF+By0zzdq OlwiTZxRbIU5YX9wM2mkUQkV9vpXqaAjV3RLxEz/8BYj19935B4a9TeGHGv+aYZOdt3r F1Uw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Nvh7RACo42xwTP6PiFcKgqzxCoNF4kiCpmi1UJgvq1U=; b=BHyvhoPPtm1wQ2Qc2FLl5N2EgYYEs/Id41CXABcjRJVnMJVppxPsR51XN2mlJpQabt rbLC2aBlZVVfc33CkPAICwTwv+y4j0TmxA9VXjGEd7bQbHa8MJjQ6L8goHdW6RN8cNOQ doko/BJo6E3tchcxulAUfPpoaR2n1dlE2lfaEN8wO0mkXzvA2eQTwzmcZGh/5AgPkhbb 2HyTlkNi4i9TqOxmJOhk+idtCa8Bjrqxb6fT//7yxtkJrUKhjRAURKFHEZLc0tIDjaAA 5c9ARBHMR82JTgyGvhVhS7XSOA0JlCgwmzbt2Jb/mCY7JL56cxTZ094pCH3v7T37jHgA b5rg==
X-Gm-Message-State: AElRT7E1uubpoJcD3BdmFFX/1d8+Fj1omX5OV637PL/TK7SIeb6MyJi0 662eymrdaTbV8UWXqWZhT4+AcqWuOmTfpAfPEzRekg==
X-Google-Smtp-Source: AG47ELsy5joI5kBpbUbwA6uy6bKbR9AZOm2gwz68YBZ40RL7UEZGc/a5Ixdt6ajL5+WZpopsXKh55p+wqWEPyU9877M=
X-Received: by 10.28.84.19 with SMTP id i19mr2508881wmb.7.1520031162810; Fri, 02 Mar 2018 14:52:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.152.235 with HTTP; Fri, 2 Mar 2018 14:52:02 -0800 (PST)
In-Reply-To: <CABkgnnWJMipRtG-p0EoUXmK3u1c2ab-v4xN3WZfm3XL8s08aZA@mail.gmail.com>
References: <CABkgnnWJMipRtG-p0EoUXmK3u1c2ab-v4xN3WZfm3XL8s08aZA@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
Date: Fri, 02 Mar 2018 17:52:02 -0500
Message-ID: <CAHw9_iKmj_CYNwm+i6ETKF3FSVwEp-NGVfiMfPiBE3QCUbKzkQ@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: captive-portals@ietf.org, Olafur Gudmundssen <olafur@cloudflare.com>, Paul Ebersman <ebersman-ietf@dragon.net>, Steve Sheng <steve.sheng@icann.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/cAj_jquon-U84iWxUuCCSTQ7J28>
Subject: Re: [Captive-portals] Fixing RFC 7710
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 02 Mar 2018 22:52:47 -0000

On Thu, Mar 1, 2018 at 10:58 PM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> We've had a number of discussions in the captive portals group about
> fixing RFC 7710.
>

As one of the original authors of RFC 7710, I fully support this!

> Erik and I would like to propose a plan for that work.  We would keep
> this to addressing the issues that we have identified thus far.
> Namely:
>
> 1. The purpose of the URI is not well defined.  We would reference the
> capport architecture and API documents for that.  The group would need
> to decide between:
>   a. point to the API
>   b. point to a login page
>
> 2. There isn't a clear way to signal that there is no captive portal
> in the network.  It has been suggested that we use a special URL -
> e.g., urn:ietf:params:capport:unrestricted. Alternatively, we could
> privilege the empty string, but that doesn't have as clear a signal of
> intent.

Oooh, I like the special URL idea -- initially the thought was a combination of:

1: Until this is ubiquitously deployed (ha!), devices will need to do
CP heuristics, and so will discover the lack of CP through that.
2: If there is no CP, no-one is likely to include the option.
3: Since the vast majority of networks don't use CPs, is this an undue
burden on them?

>
> 3. RFC 7710 states that the URL SHOULD use an address literal.  This
> works at odds with the idea of using HTTPS.

Yeah, there was a significant amount of discussion on this at the time
of the original document -- I can probably dredge it up if needed, but
IIRC, it focused around the fact that 1: many clients behind a CP
would not have enough working connectivity to be able to do the DNS
stuff required to be able to validate the cert, and 2: a lack of
clarity on what exactly would be authenticated.

I'm at Washington Dulles airport, connect to the IAD_Free_WiFi SSID
and get a URL of https://www.your-preferred-internet-provider.com

1: The cert is likely to filled with such guff as:
 URI:http://cdp.rapidssl.com/RapidSSLRSACA2018.crl
 CPS: https://www.digicert.com/CPS
 OCSP - URI:http://status.rapidssl.com
 CA Issuers - URI:http://cacerts.rapidssl.com/RapidSSLRSACA2018.crt

Many clients have static / corporate DNS servers configured -- does
the CP operator simply allow any port 53 traffic so that the user can
resolve these? If so (fairly obviously), people who want to bypass the
CP will simply DNS tunnel all traffic.
Also, does the CP operator know which IPs cdp.rapidssl.com and
status.rapidssl.com will live behind on e.g Thursday? Or do they need
to constantly resolve URLs in the cert and dynamically allow access to
OSCP / CRL servers? Or does the CP also need to OSCP stale?


2: How does the client know that your-preferred-internet-provider.com
is the identity which *should* be providing Internets? Having the
client accept that /might/ give the impression that there is some
*reason* to believe this, and was viewed as a usability concern --
training users / developers to make a leap of trust that "you should
trust this identity is the right one" was viewed as a dangerous
pattern.

Somehow this turned into "Just ship http://192.168.1.1/foo and then
that, um, someone else's problem"  -- before everyone jumps down my
throat, I'm not arguing for or against the positions, rather trying to
provide some background on how we ended up here. :-P


>
> Is there anyone who is willing to take on this work?  We aim to start
> and complete this work in <1 meeting cycle, starting in London.

I don't have the time to be the only / primary author, but I'd be more
than happy to help co-author (if that would be useful), contribute,
review, fold, spindle or mutilate -- whatever would be helpful.

>
> For the authors of RFC 7710, let us know if you have any concerns.

Speaking for myself: Good -- I'd like it if this became more useful -
my only concern would be the work *not* being done (I'm obviously
perfect in every way, including having the modesty to know my work
could be improved upon :-P )

W


-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf