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

Barry Leiba <> Sun, 10 May 2020 23:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E049C3A0B5C; Sun, 10 May 2020 16:28:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.399
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id x_9-13S7Ic-0; Sun, 10 May 2020 16:28:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4078A3A0B28; Sun, 10 May 2020 16:28:24 -0700 (PDT)
Received: by 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;; 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: <> <> <>
In-Reply-To: <>
From: Barry Leiba <>
Date: Sun, 10 May 2020 19:28:12 -0400
Message-ID: <>
To: Linda Dunbar <>
Cc: Joe Abley <>, "" <>, "" <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="00000000000022e4e005a55396f4"
Archived-At: <>
Subject: Re: [Captive-portals] [Last-Call] Opsdir last call review of draft-ietf-capport-api-07
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


On Sun, May 10, 2020 at 7:18 PM Linda Dunbar <>

> 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: <> On Behalf Of
> Joe Abley
> Sent: Saturday, May 9, 2020 5:42 PM
> To: Linda Dunbar <>
> Cc:;;
> 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 <>
> 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