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

[Yoav Nir <[e-mail]>]

Hi, Andy

On Mar 19, 2014, at 6:45 PM, Andy Lutomirski <[e-mail]> wrote:

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

I’m sure you can add a PAKE to TLS, and it’s already been done. There’s SRP.  The fact that (as you said) it is hardly used suggests that there is not much demand for it.

I would argue that at least for the web (it may be different for IMAP) the TLS layer is a really bad place to do the password exchange. The application designers at https://www.example-bank.com, even assuming that they are OK with getting a browser UI for authentication, don’t want to get that on the landing page. That page should have grand marble structures and loan offers and most important, information that is available to non-customers. You only want to pop up the browser UI after the user clicks a “Log in to my account” button.  That is hard to do in the authentication is in the TLS handshake. See a discussion about client certificates on this and the http-bis list just a couple of weeks ago.

Of course, the assumption above is bogus, because as Ryan said, application designers don’t want to use the browser UI. There is some work being done to make authentication at the HTTP layer more appealing to them (see https://www.rcis.aist.go.jp/special/MutualAuth/  There’s even a modified Firefox and a test server ), but I don’t have high hopes for this succeeding. BTW: that work is done in conjunction with a PAKE proposal for HTTP, which is not what the designers want, but it a more appropriate layer than the transport layer. Over at http-auth we are working on standardizing that http-layer PAKE, but I don’t think it will get much use.


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

Never say never, but so far getting users to avoid doing what they intended to do just because there is some weirdness has not been successful. When faced with a different UX, people will assume that the bank has made a UX revision rather than that they are being attacked. Most of the time, they would be right. If people walked away in the face of a severe UX change, Facebook would have died five times by now.

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

The thing is, as long as the authentication happens in the application layer, none of the fancy crypto matters. If my bank implements a PAKE in the login screen using Javascript, a decent web designer can make a website that looks identical, only the passwords go in the clear to the phisher, and there is no fancy PAKE javascript. Good crypto in indistinguishable from bad crypto or no crypto at all.

Yoav