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

[Andy Lutomirski <[e-mail]>]

I'd like to see TLS 1.3 solve what I consider to be two major problems
in past versions.

1. When clients authenticate with a password, if they send their
password to the wrong server, that server learns their password.  This
is the basis of most phishing attacks.  (I'm ignoring TLS-SRP, which is
basically unused.)

2. If a client uses a client certificate, the client has to store the
private key *and* certificate associated with the certificate.  That
means that any encrypted form of that certificate is subject to a
dictionary attack.

Both of these problems can be solved if the default mode of client
authentication in TLS 1.3 were an augmented PAKE or a non-key-exchanging
equivalent.  #1 is addressed directly, and it would even be safe to
share passwords between different servers.  #2 is also solved: a client
certificate could be some identifying information (which does *not*
contain a PAKE verifier) and a high-entropy "password" encrypted with a
real password.  As long as the encryption doesn't provide a way to check
whether the key is correct, no one can brute-force the client's password
without a round trip to the server for each guess.

It might make sense to use similar techniques to authenticate servers to
clients.  First, symmetry is nice.  Second, I think that several of the
protocols for doing this kind of authentication are actually *faster*
than using digital signatures.

Should TLS do something like this?  This may fit in with Watson Ladd's
suggestions about using something other than conventional DH for key
exchange.

--Andy