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

On 07/14/2015 10:43 PM, David Farmer wrote:
> OK fine TLS, but don't pick on me, Ted you said SSL in your list, I 
> was just going off of that. 
Sorry, that was as much for my benefit as yours.   You are right that I 
tend to use the terms interchangeably, but the time has definitively 
arrived at which we need to stop doing that.
> However, I'm not sure it really makes that much difference, it isn't 
> what our captive portal does that will be your issue it's what be bad 
> guy's captive portal does and there ain't much we can to about that. 
> And I'm not sure how much TLS will really help there, as SAM points 
> out domain names and certificates are that hard to come by, not really 
> an excuse for the good guys to not do it, but its not going to fix the 
> problem either.
The point of saying that captive portals have to support TLS and 
DNSSEC+DANE is to arrange it to be the case that only bad guys have 
unsecured portals.
> The only thing we can really do is NOT have you use insecure open 
> wireless by providing secure wireless options.  But, I'm some what 
> depressed by the number of people who WANT to use insecure open 
> wireless for many reasons, ease of use, anonymity, etc... 
The main reason they want to use them is because they work. Remember, 
secure != non-private.   The captive portal can collect information 
about the user, but it doesn't have to.   The main reason people use 
broken or non-secure captive portals is because it's so hard to make 
captive portals that are secure, so by and large captive portals simply 
are not secure.
For instance, suppose I want to sell a router that has a captive portal 
mode that can be enabled by the end user.   How do I make that work 
without requiring the end-user to buy a cert?   Right now the answer is 
that I don't, because no browser supports DANE certs.   How do I do 
secure password-less logins?   I don't, because there isn't a good and 
well-supported standard for doing that, even though we know how.
So part of what we should be doing to make Christian happy is to finish 
the specifications for these security technologies and see them deployed 
in browsers and servers.   There is no reason other than our failure to 
do this that it should be the case that I have to log in to my Wifi 
router using an unencrypted connection that reveals the username and 
password I use to authenticate, much less that captive portals should 
have to either not be secure, be secured with an expensive SSL 
certificate infrastructure, or be "secured" with a key that can't be 
validated.