Another entry in the internet security hall of shame....

[Peter Gutmann]

Stephan Neuhaus <neuhaus at st.cs.uni-sb.de> 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 majordomo at metzdowd.com