Ballot for draft-wkumari-dhc-capport
Yes
No Objection
Note: This ballot was opened for revision 14 and is now closed.
Glad we got the document status thing sorted out.
At least some of the authors should know from earlier conversations that I very much support going ahead with this document. Just one teeny comment: -- Section 2 -- In order to avoid having to perform DNS interception, the URI SHOULD contain an address literal, but MAY contain a DNS name if the captive portal allows the client to perform DNS requests to resolve the name. In my continuing effort to eradicate 2119-use problem #1: the SHOULD/but-MAY structure is a bad one; "SHOULD" is strong and "MAY" negates it. It's not really a problem here because your "if" constrains the scope of the "MAY", but I'd prefer it if you'd rephrase it something like this: NEW In order to avoid having to perform DNS interception, the URI SHOULD contain an address literal. If the captive portal allows the client to perform DNS requests to resolve the name, it is then acceptable for the URI to contain a DNS name. END Note that's "I'd prefer it"; if you disagree, that's the last you'll hear of it from me, and there's no need to discuss this point.
There are lots of TBDs in the shepherd write up. Some are fairly important (i.e. the IPR questions) -- section 2: Are there any rules about the nature of the uri? Scheme? Security? -- section 4, last paragraph: Would it make sense to have a stronger statement about TLS for privacy purposes, given that captive portals often ask for passwords? Also, It might be worth elaborating on the "assure users a portal is not malicious" part.. editorial: -- 4, last paragraph: "By handing out a URI using which is protected with TLS, ..." Looks like an editing error around "using which"
I think you need to specify somewhere that the URIs are encoded following the rules in RFC 3986.
I find this paragraph a little confusing an think it could be a bit cleaner: "Devices and systems that automatically connect to an open network could potentially be tracked using the techniques described in this document (forcing the user to continually authenticate, or exposing their browser fingerprint). However, similar tracking can already be performed with the standard captive portal mechanisms, so this technique does not give the attackers more capabilities." I think just a variation of the second sentence is enough as this mechanism doesn't introduce any new tracking mechanism. Just stating that it is possible to track users from a network with a captive portal should be enough. As a side note, I know this is out of scope, it would be interesting as a user to understand policies of captive portals using this mechanism before selecting which to use. Maybe some set of registered policies that go in the URI for the future?
Thank you for producing this draft. I hope the mechanism it describes is widely deployed. It's a small thing, but this draft uses "authenticate" in the abstract, and "agree to an acceptable use policy (AUP) and / or provide billing information" in the Introduction, and then talks about "an authentication page" in section 2. Are all those synonyms, for those skilled in the art? If not, more consistency might be helpful, or perhaps adding a definition of "authenticate" that includes things like agreeing to an AUP.
Address literal URIs don't play well with https, do they? And using https here is desirable as credentials are likely to be sent. And while a 30x to a https URL can be used, that round-trip could allow for new points of attack, for an adversary not able to insert a DHCP response. (E.g. if the evntual https TLS endpoint is far from the WLAN, then the http URI could be more easily attacked.) Maybe you ought note this issue? Or... Why not send the URI and optionally the address? That way a standard CA could support https, and a client with no DNS could still be ok. Not sure if the client could benefit from standard URL de-referencing code though, so this may be a dumb idea. OTOH, you're already calling for special sandboxing of that (usually) web page, so maybe this could work?
Nothing against the draft itself, but a reflection. I'm sure we all faced this issue: In an airport, with lots of WIFI networks, we connect to each of them one by one, hoping for a free WIFI for a few minutes to exchange emails, and it takes a long time to "test" every network". I can envision the solution in the draft to be used to provide the list of all WIFI networks along with the associated portal page (after a quick DHCP request for each WIFI), to help me select my network. In this multi providers configuration, what is the incentive for the different captive portals to populate this field. All the providers want to attract customers to their portal, and show how great/cheap their services are. So not populating this field might trick me to believe that there is a direct connection to the Internet and influence my WIFI selection. Nits: - RA acronym in the abstract - AUP acronym - idnits complaints about the 'RFC2939' missing reference - remove ">" in "Captive portals are increasingly hijacking TLS connections to force > browsers to talk to the portal." .