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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07/14/2015 12:24 PM, David Farmer wrote:
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.

The issue is that we want to avoid being infected by malware, and if the captive portal controls all of our access to the information we'd use to avoid connecting to an untrustworthy source, we are in trouble. Chances are that your marketing splash is some kind of flash or javascript thing, and we'd like to be able to know that we are really talking to you and that you aren't on a malware blacklist. DNSSEC and TLS (not SSL, all versions of SSL are known to be vulnerable to hacks of various kinds) are required to make this work.
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.
I think by writing this draft, Warren is acknowledging that there is a business case for captive portals, and by not rejecting the advancement of the document, the IETF would be agreeing.




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]