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

["Ryan Sleevi" <[e-mail]>]

On Wed, March 19, 2014 8:43 am, Andy Lutomirski wrote:
>  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:
[Snip]
> >>  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.

Challenge: Go find a site using HTTP auth (of any form - BASIC, DIGEST,
etc), that wasn't built in the 1990s or a slow-moving SDO.

Ask them how they like it.

Answer: They don't. No site wants to use browser UI. It's a bad UX.

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

And the ocean can be boiled to power a giant steam engine. These are both
true statements, but both discount the huge efforts for the minimal gains
and real harm possible.

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

Which was exactly my point.

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

It's not a technological issue. It's a social/usability issue.

And the TLS WG is, arguably, one of the least suited of all WGs to solve
this.