Can the TLS 1.3 PSK-DHE handshake be turned into a PAKE?

Question

Recently, we had the question whether there's a PAKE that uses more standard, higher-level primitives than what SRP offers.

Now this made me think and ask myself: TLS does have a PSK mode, can't we leverage that? This shall be the theme of this question.

What I would imagine is the following exchange:

• Client -> Server: "Hi, I'm [email protected]"
• Server -> Client: "Here are your key derivation parameters: ..." and the server also sends his regular key exchange message assuming the client is who he claims to be
• Client -> Server: sends his key exchange part

The idea is that we basically do standard TLS-PSK using the hashed password, so the server can store this hashed version and the client can re-calculate the hashed password (the PSK) on-the-fly.

Now at least for TLS 1.2 this is impossible if you don't have a custom ClientHello extension, because the ClientKeyExchange is sent after the ServerKeyExchange.

For TLS 1.3 (draft 18) things are more intriguing. It appears that Client can send a list of key labels and the server picks one. I don't exactly understand whether there is another message from the client with his key exchange part.

So now very concretely my question:

Can we somehow fit the above flow of log-in into the TLS 1.3 handshake, without defining our own custom extension?

Answer 1

The current TLS 1.3 draft proposal with PSK does not have PAKE properties; in particular, a client can send a single message, get a reply, and then check every entry in his dictionary to search for the PSK used by the server.

To do this, the client would send a valid hello, specifying the identity that the client is interested in (and a valid keyshare). The server will also generate its key share, generate a key that's based on the psk, and the key share shared secret, and encrypt some data based on that key. Then, the client computes the key share shared secret (which doesn't depend on the PSK), and then for each entry in his dictionary, compute what the key would be if that guess was correct, and then see if that decrypts the encrypted region into something readable; if it does, he has recovered the PSK.

I believe that the same approach would work against your proposal, with the possibility that it's the server that can do the dictionary attack; it's the first guy to receive a message encrypted by a key that's a function of the PSK.

Hashing the password doesn't add PAKE properties; the attacker can just as easily hash each entry in his dictionary, and use those.

To make TLS 1.3 into something that does PAKE, the right approach would be to integrate some protocol with PAKE properties (such as SRP or EKE) into it.