ietf
[Top] [All Lists]

Re: Gen-ART and OPS-Dir review of draft-wkumari-dhc-capport-13

2015-07-14 14:24:45
On 7/13/15 12:25 , Ted Lemon wrote:
Thinking about this a bit more, it seems to me that the advice that
should be followed in the case of a captive portal is this:

- You must make it possible to resolve any names required to register
using DNSSEC, whether you support DNSSEC or not.
- You should support DNSSEC
- You must make it possible to do all appropriate validation for any SSL
certs that are required to validate the connection to the portal.
- You must use SSL for the portal, and you must use validate-able certs.

In many cases I'm fine with these requirements, especially in the case where the purpose of the portal is authentication or some other user registration information is exchanged like an email address or a phone number. Obviously, that kind of personal information must be protected.

However, what if the only purpose of the portal is to display marketing and/or acceptance of Term & Conditions? Is DNSSEC and SSL still required in this case? I tend to think not, but I'm happy to hear why I'm wrong.

Frequently that is all the captive portal is, a little marketing and maybe T's & C's to keep the lawyers happy. For most coffee shops or restaurants and a lot of other public places this all the portal does.

My concern is that while this is really good advice, there's no real
incentive in place to get the captive portal vendors to implement this
nor to get the captive portal providers to require it or set it up
correctly.   There is some small cost to supporting broken portals, but
by and large laying this cost off on the end user works.

If we start by acknowledging the existence of business reasons for captive portals then maybe people will listen, but if all we tell them is that is a stupid idea, I'm sorry but why would/should they listen to us.

Similarly, as you say, the host software provider has no incentive to
require this functionality: for the most part, it simply makes life
difficult for the end user.   At present, Google is actually pretty good
about this; the result is that it's hard to use Google devices on
networks with broken captive portals, which are of course endemic.
Google seems not to have paid a price for this thus far, but I don't see
other vendors doing what Google is doing.

Google in particular is on all sides of this problem, they make a browser, they make an Client OS, and they are becoming a provider and/or sponsor of connectivity is places. I have some hope we can make things better in this realm.

Thanks.

--
================================================
David Farmer               Email: farmer(_at_)umn(_dot_)edu
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================