Re: [Captive-portals] [Last-Call] Opsdir last call review of draft-ietf-capport-api-07

Barry Leiba <barryleiba@computer.org> Sun, 10 May 2020 23:28 UTC

Return-Path: <barryleiba@gmail.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 E049C3A0B5C; Sun, 10 May 2020 16:28:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 x_9-13S7Ic-0; Sun, 10 May 2020 16:28:24 -0700 (PDT)
Received: from mail-io1-f48.google.com (mail-io1-f48.google.com [209.85.166.48]) (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 4078A3A0B28; Sun, 10 May 2020 16:28:24 -0700 (PDT)
Received: by mail-io1-f48.google.com with SMTP id x5so1350482ioh.6; Sun, 10 May 2020 16:28:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0sT9VeXKboDWwoMAL4q43nRDPUu/OiQtmrUoiCieTt8=; b=quDFzTdDp4AcfcSHX0JucQy74GmbUFcXIDWWO0HrN7bbz1gw/CPm0/nR6Bl+ify3SD 7b7lgMKxP28C778sOgAdeR7IeHlJlJiRpfO19eeIJfKuX66wgWjc27IwEG2ndQLkJqup ZZ70539Csk8Q9uYE1GJo3YRUu5PoRUyIi535mNjMICI6zX60QNi+sKL7JTAGVEfdym+6 kGWNXG0kAJ9EEkW+3U8kWo3i5dzgmHtk+scFiKoYnJhv8/Gi2uah7/whOuMbOygeEz2b yPaFAc4RcHtDSVpVEFVscq/S8TcgqOVOxeZpRgCKD6pBg3C0zcn96nRH6oxViOriyL2m UlkA==
X-Gm-Message-State: AGi0PuZlN7Q9Ty+gsx0nRJsH4AxE2JwYkFiqieAiWrcXG5YJaLK+E3Jg xEyzMnTiUAWLHsBHBBLnoOQ64X+OqawqbAJ6Zv8=
X-Google-Smtp-Source: APiQypJpWXGYoV8As8ch9Jc6I+Ot0kK5zJ+NWsQ65vDVQA5AL/zF5cPMrLvY5ZbeVDqMO0C1a8XbHveltWRHd9kg04k=
X-Received: by 2002:a02:5807:: with SMTP id f7mr1440549jab.118.1589153303289; Sun, 10 May 2020 16:28:23 -0700 (PDT)
MIME-Version: 1.0
References: <158906200797.26124.16073204264263445484@ietfa.amsl.com> <9AB2F3DF-0AE7-4ABE-82F3-5FFD7B341D51@hopcount.ca> <SN6PR13MB2334711D0A2CAAAEFAA988B685A00@SN6PR13MB2334.namprd13.prod.outlook.com>
In-Reply-To: <SN6PR13MB2334711D0A2CAAAEFAA988B685A00@SN6PR13MB2334.namprd13.prod.outlook.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Sun, 10 May 2020 19:28:12 -0400
Message-ID: <CALaySJ+fHSJ1=EOD67=-q30_3=k=__x6Q_uCcPfE+MSCDLc-6A@mail.gmail.com>
To: Linda Dunbar <linda.dunbar@futurewei.com>
Cc: Joe Abley <jabley@hopcount.ca>, "captive-portals@ietf.org" <captive-portals@ietf.org>, "draft-ietf-capport-api.all@ietf.org" <draft-ietf-capport-api.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "ops-dir@ietf.org" <ops-dir@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000022e4e005a55396f4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/ifJIa-BfJ_pL0sSkC_zhmhhGpQA>
Subject: Re: [Captive-portals] [Last-Call] Opsdir last call review of draft-ietf-capport-api-07
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: Sun, 10 May 2020 23:28:26 -0000

Hi, Linda, and thanks for the review and follow-up.  I don’t agree that
much (or any) more needs to be said in this document: that’s what normative
references are for.  If the architecture document isn’t clear enough about
what we’re doing and why, then I think that is the place to address it.

Barry

On Sun, May 10, 2020 at 7:18 PM Linda Dunbar <linda.dunbar@futurewei.com>
wrote:

> Joe and Tommy,
>
> Thank you very much for the explanation. They are very helpful. I don't
> recall those useful information when I  glanced through the
> draft-ietf-capport-architecture. IMHO, those information would be useful to
> be added in the Introduction section.
>
> Linda
>
>
> -----Original Message-----
> From: mjabaut@mail.hopcount.ca <mjabaut@mail.hopcount.ca> On Behalf Of
> Joe Abley
> Sent: Saturday, May 9, 2020 5:42 PM
> To: Linda Dunbar <linda.dunbar@futurewei.com>
> Cc: ops-dir@ietf.org; last-call@ietf.org;
> draft-ietf-capport-api.all@ietf.org; captive-portals@ietf.org
> Subject: Re: [Last-Call] Opsdir last call review of
> draft-ietf-capport-api-07
>
> Hi Linda,
>
> On 9 May 2020, at 18:06, Linda Dunbar via Datatracker <noreply@ietf.org>
> wrote:
>
> > Reviewer: Linda Dunbar
> > What improvement does the proposed API have over today's existing
> > communication between clients and  Captive Server(s)? Captive servers
> > have been deployed everywhere, like airport or restaurants trying to
> > access free WIFI. What problems does the existing method have to justify
> this newly proposed APIs?
>
> I have no involvement with this architecture apart from being an
> enthusiastic cheerleader on the sidelines, but it seems to me that none of
> the existing captive environments you mention have anything resembling a
> structured, machine-readable interface. So this is not a newly-proposed API
> so much as the first and only example of a standard API we have for this at
> all.
>
> Existing mechanisms rely upon devices being configured in a particular way
> (e.g. DNSSEC validation disabled, DHCP-provided DNS server being used,
> DoH/DoT disabled), they rely upon users using particular applications to
> trigger an interaction to escape the captive environment (e.g. a browser),
> they provide no clear indication to client software that a captive portal
> exists, leaving the client to try to infer whether the network is simply
> broken or whether it is encumbered and it's rare that two such environments
> you encounter on any particular day act the same. They also often trigger
> certificate warnings in software like calendars and mail readers that I
> have seen users click OK on, imagining that they are gaining access to the
> network by doing so, whereas in fact they are just facilitating an on-path
> attack on TLS so that their credentials can be stolen.
>
> While some widely-used devices have come to be accommodated more elegantly
> than others through simple market dynamics (e.g. giving iPhone users a
> smooth experience reduces support costs and increases revenue) the general
> experience is, putting it mildly, horrific, wildly inconsistent and hostile
> to users.
>
> The companion architecture document draft-ietf-capport-architecture-07
> contains a brief description of some common components of existing
> mechanisms in its appendix A, but I think the variety deployed in the world
> is wide enough that it's reasonable for that document not to try go into
> any more detail. In any case I don't think this document
> (draft-ietf-capport-api-07) needs any such narrative; I think the
> architecture document is a better place for it.
>
> [Having been so rude about existing mechanisms, I will mention wistfully
> that I do very much look forward to the day when I can be horrified by wifi
> in airports and coffee shops again.]
>
>
> Joe
>