Captive-Portal Identification Using DHCP or Router Advertisements (RAs)
draft-wkumari-dhc-capport-16

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?