Captive-Portal Identification Using DHCP or Router Advertisements (RAs)

Note: This ballot was opened for revision 14 and is now closed.

(Alia Atlas) Yes

(Ben Campbell) Yes

Comment (2015-09-16)
No email
send info
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..


-- 4, last paragraph: "By handing out a URI using which is protected with
   TLS, ..."
Looks like an editing error around "using which"

(Alissa Cooper) (was Discuss) Yes

Comment (2015-09-14)
No email
send info
Glad we got the document status thing sorted out.

(Spencer Dawkins) Yes

Comment (2015-09-16)
No email
send info
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.

(Stephen Farrell) Yes

Comment (2015-09-15)
No email
send info
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

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?

(Brian Haberman) Yes

Comment (2015-08-28 for -15)
No email
send info
I think you need to specify somewhere that the URIs are encoded following the rules in RFC 3986.

(Joel Jaeggli) Yes

(Barry Leiba) Yes

Comment (2015-08-21 for -14)
No email
send info
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:

   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.

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.

(Kathleen Moriarty) Yes

Comment (2015-09-16)
No email
send info
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?

(Jari Arkko) No Objection

(Deborah Brungard) No Objection

(Benoît Claise) No Objection

Comment (2015-09-15)
No email
send info
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.

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

(Terry Manderson) No Objection

Alvaro Retana No Objection