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

[Andy Lutomirski <[e-mail]>]

On Wed, Mar 19, 2014 at 9:20 AM, Ryan Sleevi <[e-mail]> wrote:
> 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

It works, but not the first time and it's tricky to do safely from the
server's POV.

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

I've never seen anything resembling a usable implementation of DANE.
It needs a way to pull a whole DNSSEC signature chain from a DNS
server (barely supported with current software -- the CD flag can do
it, but client code doesn't seem to support that well) or using a
nonexistent TLS extension.

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

The only reason I think my suggestion is reasonable is that I think
that it could be very simple -- the main TLS key exchange be designed
to have all of the necessary cryptographic properties to be an
augmented PAKE.  People who don't want to use it can specify null
passwords.

[...]

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

Right.  And the better websites (banks?) will offer both and users
will learn that, when they're at home, they should only use the
trusted password prompt.


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

Please read the other half of my original email and most of my
replies.  I think that, even when using a second factor device (e.g.
Fido, which you brought up), using an augmented PAKE style challenge
for the device could improve security.  This has no UX issue at all --
the whole technology is new, and the UI workflow suggested in the
draft specs seems like it would work just fine with an improved
challenge-response protocol.

--Andy