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

[David Farmer <[e-mail]>]

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: [e-mail]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: [phone]
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================