On Tue, March 18, 2014 2:55 pm, Andy Lutomirski wrote:
>  On 03/18/2014 02:13 PM, Daniel Kahn Gillmor wrote:
> >
> > Hi Andy--
> >
> > Thanks for raising this question.
> >
> > On 03/18/2014 02:11 PM, Andy Lutomirski wrote:
> >> 1. When clients authenticate with a password, if they send their
> >> password to the wrong server, that server learns their password.
> >
> > I think you're talking about HTTP basic auth here, or IMAP AUTH=PLAIN,
> > right?  Other authentication mechanisms that are layered on top of TLS
> > don't necessarily have the same concern.
>
>  As far as I know, pretty much all authentication methods that layer on
>  top of TLS either have this problem or are, at the very least,
>  vulnerable to dictionary attack by a rogue server.  Getting secure
>  augmented password-based authentication right is tricky, and I think
>  that TLS should offer this service.
>
> >
> >>  This
> >> is the basis of most phishing attacks.  (I'm ignoring TLS-SRP, which is
> >> basically unused.)

Since you raised "phishing" as your concern, I'm entirely responding
within the context that you're talking about user-facing actions within
the context of a web browser. I have yet to hear of a good mail client
"phishing" attack (you *are* validating your IMAP certs, right?), so this
seems almost predominantly an issue of attacker-controlled UI - that is,
the web.

> >
> > TLS SRP's lack of use suggests that there is not a high pressure for
> > deployment here.
> >
> > It's probably worth thinking some about why SRP adoption has been so
> > slow (i don't know the global answer here, but i only know a few folks
> > who are using it)
>
>  I'd guess it's a chicken-and-egg problem.

No. It's really not. It's a usability problem, and one that doesn't get
solved easily.

It's not unique to TLS-SRP. It's just as applicable to TLS client
certificates.

Browsers don't want it:
- It requires the browser implement a special (trusted) UI, since by
definition, it's the browser's responsibility to terminate TLS
connections.

Sites don't want it:
- Sites don't want to force browser UI on their users, they want to
control and customize the UI. They want to handle failures, not rely on
browsers that may or may not handle errors in the manner in which they
desire.

Users don't want it:
- Users *like* sites' form-based authentication. It integrates easily with
their mental model, provides easy avenues for trouble-shooting ("forgot my
password", etc).

This is the exact same problem with client certificates.

Both solutions (TLS-SRP and client cert auth) are trying to solve
application auth issues at the transport. This doesn't work well. Heck,
even GSSAPI doesn't have a good solution for this when authenticating to
sites with SPNEGO (although the ongoing work for cred UI is exciting
stuff).

The real drive - of sites and of browsers - is trying to find ways to give
sites as much control of the UI as possible, while simultaneously reducing
the risk - of password breaches and security incidents. If you want to see
the practical efforts to "solve" the phishing problem, look at stuff like
http://fidoalliance.org/

There are still be opportunities to improve things within TLS - channel
bindings being the most obvious issue at hand.

Sites - and browsers - want assurances similar to client certs, but
without all of the countless headaches (eg: Define a reasonable way to
"Log Out" in the case of CCA when talking to a website, where you may have
N parallel connections, which may have Y TLS sessions depending on timing,
and which have a whole host of internal state full of spit-and-glue just
trying to make CCA semi-usable for HTTP)

I'm hard-pressed to find a use case for TLS-SRP in the context of the web,
nor do we hear sites really clamoring for it, and an augmented PAKE is
just same story, different day.

If you're talking outside the context of the web, then maybe there's a use
case, but my instinct is "meh". I think you'll be hard pressed to find
anyone who really loves passwords or thinks we should encourage more of
them.