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

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

On Wed, March 19, 2014 9:06 am, Andy Lutomirski wrote:
>  On Tue, Mar 18, 2014 at 10:54 PM, Ryan Sleevi <[e-mail]>
>  wrote:
> > 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.
>
>  Even for IMAP, using PAKE, augmented or balanced, would give a
>  significant amount of protection against MITMs who have compromised a
>  CA.  Since compromising a CA seems to be a popular thing to do these
>  days, resisting these attacks at the protocol level would add
>  considerable value.
>
>  --Andy
>

Or use key pinning - http://tools.ietf.org/html/draft-ietf-websec-key-pinning

Or use DANE - https://tools.ietf.org/html/rfc6698

My point is you can see on this list archives two common threads:
- A desire to reduce, as much as possible, the complexity of TLS
- Not a lot of fondness for another PAKE

I applaud your zeal, and my hope and goal is to try to highlight that
you're trying to solve the wrong problem. On the browser side, on the site
side, and the user side - your target demographics - no one is really
saying "Aww, if only I had a PAKE! That's what my security solution
needs".

If you're still convinced that *this* is the thing that TLS is missing, I
would only encourage you to reach out and try to first come up with a
solution for "how the password gets in the browser" before trying to
figure out how the browser gets it to the server. That will at least burn
a decade of energy and enthusiasm.

Note that the solution equally fails to meet your goals, because you will
always have browsers that don't support your solution - so sites wanting
to use it will still have to support 'naked' passwords. Equally, for
browsers, there will always be sites that continue to support the <input
type="password"> authentication (not the least because it's part of
HTML5), so they will always be phishable via downgrade attacks - not of
the TLS type, but of the UX type.

So your goal of providing a more secure UI is not really achievable, and
where it is, it's not really secure.

If that's the only justification/goal for the augmented PAKE (and your
replies suggest it is), let's just save the trouble and say "meh".