CAPtive PORTal interaction
charter-ietf-capport-01

I agree with Spencer's comment about MiTM attacks.

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.

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?

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?