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.