Stephan Neuhaus <[EMAIL PROTECTED]> writes: >I think you're talking about me here,
Oh no, I wasn't focusing on any one person, it was a characterisation of the general response from security people when this sort of thing is mentioned. Long before the discussion on this list, there were already missionaries coming to the ietf-tls list to enlighten the heathens who dared to mention PSK and remind them of their duty to support PKI in all its infinite perfection, and not to take any false gods before it. >I also didn't say that passwords didn't *work*, I said that they had *storage >and management issues* that certificates did not have and that their >deployment would be problematic because of that, and I stand by that. Sure, but those issues have already been addressed by pretty much every site that needs to use passwords or user authentication for any reason. That's the point I was trying to make, that the standard response to use of passwords (or PSKs) is they don't work, they don't scale, you can't handle revocation, distribution is a problem, etc etc etc. However, despite all of these issues, all the sites that need to authenticate users are using passwords, and they seem to be doing OK with that. >Rather, it is my impression that a switch to TLS-PSK would not just be a >client-side thing, but that server code would have to be changed also, and >that it is this issue which will prevent widespread deployment of TLS-PSK. Sure, that will be an issue. I think it depends on how much pain banks and merchants are willing to endure due to phishing attacks. The problem with current authentication methods is that the authenticated is in completely the wrong direction to prevent phishing, and the phishing industry has developed in response to the fact that TLS server cert-based auth is useless against it. TLS-PSK addresses this problem. Not only does it authenticate the server, but it authenticates it in a manner that proves the server has direct knowledge of the client, not merely that they've shelled out all of $7 for a server cert. So in other words I could be directed by phishers to dozens of sites all claiming to be XYZ Bank, some even with TLS certs proving this, but only one will be able to authenticate itself to me as my bank. If you look at this in terms of attack surface reduction, it's gone from: The software I use will hand my password over (in plaintext) to anything claiming to be my bank. to: An attacker will have to get to me during the enrolment phase, or compromise the bank's server to steal the passwords. This is an *enormous* reduction in attack surface. Compromising the enrolment phase would typically require a huge spoofing effort or powerful MITM, much more than the "spam out a plausible password-renewal request" type of attack that's been so successful against the current way of doing things. >If I were a phisher, I'd set up a web site having normal text boxes for >username and password. On it, I'd put a link "why isn't the URL bar blue?" >and use some technical mumbo-jumbo about how for technical reasons, the >feature needed to be disabled in the browser, Yeah, that's still a possibility, although I think you can probably train most users to not do this. I only know about NZ banking practices here, but every one of them provides a best-practices way to do things (don't do banking from an Internet cafe, check for the padlock, when logging on check that the last- logon time display was when you actually logged on, etc etc). Drilling it into people that if they don't see the blue flashy bits there's a problem shouldn't be that hard. Sure, there'll be some margin-of-error group who still won't get the message, but these same people would also hand out their credit card details over the phone to someone claiming to be from their bank. The thing is, TLS-PSK provides major attack surface reduction, and that's a big win in the fight against phishing. Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
