CAPtive PORTal interaction
charter-ietf-capport-01

[Ballot comment]
What's the relationship with draft-wkumari-dhc-capport-16?

Any value in mentioning it in the charter?
"Building on/Integrating/Improving/... (*) draft-wkumari-dhc-capport-16 (RFC editor queue), the WG will ..."

(*) depending on the answer to the first question

[Ballot comment]
The phrase "satisfy the requirements" is pretty ambiguous. I would suggest either explaining what requirements are intended (e.g., "the network operator's requirements for obtaining network access" or something along those lines) or dropping the phrase altogether if the point is really just to provide the URL.

[Ballot comment]
Warren responded nicely to my comment on the 00-01 version about

"As endpoints become
inherently more secure, existing interception techniques will become
less effective or will fail entirely."

and I understand that a previous version that attempted to say "inherently more secure because X mechanisms are being deployed" was problematic, but the current text still sounds like we're thinking happy thoughts, and I know you aren't.

Would it be any less problematic to say "inherently more secure in response to X security threats"? Where X might be "pervasive surveillance", "DNS spoofing", etc?

"No" might be a perfectly reasonable answer ...

[Ballot comment]
The CAPPORT Working Group will define secure mechanisms and protocols to
- allow endpoints to discover that they are in this sort of limited
  environment,

I'm not personally convinced that capport will necessarily be more successful then DHC in securing initial signaling which strongly implies to me that we should not constrain it in this way.

that said I think further along in process (vending a webpage) other security mechanisms come into play and that seems highly likely.

[Ballot comment]

Good to see us trying to make this better.

One question below. (I'm still a "yes" ballot regardless
of whether the answer is yes or no btw.)

Say if someone wanted to make a protocol to advertise
that such and such a captive portal exists and can be
interacted with at such and such a URL when one is
connected to such and such a WLAN/LAN/SSID in such
and such a location. Would discussing that be in scope
for the WG?

[Ballot comment]
This is important work and should go forward.

Minor comment which you can ignore: on re-reading the charter, I thought that the concepts of captive portals and roaming was a bit mixed. These are independent issues. A web-based captive portal may allow roaming, but would still benefit from the results of this working group. A non-roaming 802.1X or EAP or application-based access point would not need. I'd suggest that the real issue is whether one uses web traffic capture or automated 1X/EAP/application mechanisms to attach. In the former case the results of this working group apply; in the latter case they don't nor is there any need to add something.

[Ballot comment]
Might consider a block on this but it's readily addressed.

A stretch-goal / phase 2 work may attempt to solve this problem
for devices that have no human interaction (such as "IoT" devices).

Rather than presuppose what might be in a future charter I would simply include this as a potential issue.

one probably bad proposal is:

A secondary goal is  to look at the problem posed to or by devices that have little or no recourse to  human interaction.

[Ballot comment]
This would be great. I did have a couple of observations for your consideration.

Two comments on this text:

"Currently, network providers use a number of interception techniques to
reach a human user (such as intercepting cleartext HTTP to force a
redirect to a web page of their choice), and these interceptions often
look like man-in-the-middle attacks. As endpoints become inherently more
secure, existing interception techniques will become less effective or
will fail entirely. This will result in a poor user experience as well
as a lower rate of success for the Captive Portal operator."

RFC 7258/BCP 188 characterizes monitoring for network management as "indistinguishable from other attacks", and we're talking about actual hijacking here, not just monitoring. Perhaps it's better to say "these interceptions are indistinguishable from man-in-the-middle attacks".

("they look like man-in-the-middle attacks because they are man-in-the-middle attacks" :-)

I'm not sure what "As endpoints become inherently more secure" means. Is this a reference to endpoints using TLS by default, and refusing to downgrade to plaintext?

I thought

"These might or might not be published as RFCs, and/or might be combined in some way."

was awkward. Perhaps

"These might or might not be published as RFCs, and might or might not be combined in some way."

would be clearer?