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]

 



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.

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.

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.




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