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

From: Linda Dunbar via Datatracker <[email-masked]>
Date: Sat, 09 May 2020 15:06:48 -0700

Reviewer: Linda Dunbar
Review result: Has Nits

I have reviewed this document as part of the Ops area directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the Ops area directors.
Document editors and WG chairs should treat these comments just like any other
last call comments.

This document provides examples of the API structure between client and captive
server. The document is well written. I just have a question:

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?

Cheers,
Linda Dunbar

---

From: Tommy Pauly <[email-masked]>
Date: Sat, 09 May 2020 15:38:03 -0700

Hi Linda,

Thanks for reviewing the document.

For background on how the architecture defined by the CAPPORT WG is preferable to the non-standard mechanisms in deployment today, I’d like to point you to one of the documents referenced by the API document, draft-ietf-capport-architecture (https://tools.ietf.org/html/draft-ietf-capport-architecture).

There are several benefits, grouping roughly as follows:

- Security: Generally, solutions today require interception of DNS and redirecting HTTP responses, and incompatibility with TLS or attempts to man-in-the-middle TLS.
- Privacy: Captive networks usually rely on intercepting “user” traffic, which means a device may try to send traffic with user-sensitive names on a network and only later realize it is captive and the results are bogus.
- Functionality: Solutions today do not have a way to communicate time remaining to devices or how to extend a session, so association is often cut off abruptly.
- Consistency and early detection: There isn’t any standard way for a client device to detect that it is captive today, and there is a large variety in the way networks implement this, leading to inconsistency in user experience and timing.

Best,
Tommy

> On May 9, 2020, at 3:06 PM, Linda Dunbar via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Linda Dunbar
> Review result: Has Nits
> 
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals

---

From: Warren Kumari <[email-masked]>
Date: Sat, 9 May 2020 21:30:27 -0400

Thank you Linda for performing the OpsDir review, and also thanks to
Tommy for so quickly responding...

These were both very helpful.
W

On Sat, May 9, 2020 at 6:07 PM Linda Dunbar via Datatracker
<[email-masked]> wrote:
> --
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

-- 
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

---

From: Linda Dunbar <[email-masked]>
Date: Sun, 10 May 2020 23:18:48 +0000

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

---

From: Barry Leiba <[email-masked]>
Date: Sun, 10 May 2020 19:28:12 -0400

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 <[email-masked]>
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
>
>
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> 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
>