Re: [TLS] Should TLS 1.3 use an augmented PAKE by default?

[Andy Lutomirski <[e-mail]>]

On Tue, Mar 18, 2014 at 10:54 PM, Ryan Sleevi <[e-mail]> wrote:
> 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.

I think that browsers should do *exactly* this.  There's already one
for the lock icon -- adding one for password entry seems like a
natural extension.  Even better: users who use such a thing don't need
to be nearly as careful about checking the actual URL before entering
their password.

>
> 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.

This can be fixed.

>
> 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).

You're assuming that an augmented PAKE with a trusted UI can't do all
of that.  If a website could request a zero-knowledge proof of
knowledge of a secret, where the secret has this description next to
it and this set of extra buttons (the buttons would be plain links and
would *not* transmit the password), I think that everyone wins.  Heck,
the whole trusted dialog could be written in HTML and, as long as the
ability to submit forms were restricted and scripts were blocked, it
should just work.

Admittedly, this doesn't really fit in to my suggestion of doing it as
part of TLS key exchange.

>
> 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/

That was actually my inspiration for suggesting this feature.  Suppose
you use a second factor (e.g. Fido U2F) device to authenticate to your
bank.  You've set a PIN "1234".  An attacker subsequently steals your
U2F device.

If the device is well designed, locks out the key after a few tries,
is suitably slow rejecting bad PINs, and is truly tamper proof, then
everything is OK.  But that's a big if.

The problem is that using ECDSA signatures or anything like then in a
second factor is the wrong approach, I think.  If a second factor
instead answered an augmented PAKE challenge, it could be implemented
in such a way that it wouldn't be able to distinguish a correct PIN
from an incorrect PIN.  Then the server could lock out the account
after a few tries, and an attacker wouldn't be able to usefully attack
the device even if they completely broke its tamper protection.

This is mostly outside the scope of the TLS WG, but I think that TLS
could do a lot to make this kind of thing easier.

--Andy