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

[Ted Lemon <[e-mail]>]

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.