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

[Daniel Kahn Gillmor <[e-mail]>]

Hi Andy--

Thanks for raising this question.

On 03/18/2014 02:11 PM, Andy Lutomirski wrote:
> 1. When clients authenticate with a password, if they send their
> password to the wrong server, that server learns their password.

I think you're talking about HTTP basic auth here, or IMAP AUTH=PLAIN,
right?  Other authentication mechanisms that are layered on top of TLS
don't necessarily have the same concern.

>  This
> is the basis of most phishing attacks.  (I'm ignoring TLS-SRP, which is
> basically unused.)

TLS SRP's lack of use suggests that there is not a high pressure for
deployment here.

It's probably worth thinking some about why SRP adoption has been so
slow (i don't know the global answer here, but i only know a few folks
who are using it)

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

i'm not sure i understand.  the certificate is public, right?  i think
you mean that the stored public key (presumably encrypted locally) is
subject to an offline dictionary attack.  This is no better or worse
than a client with an encrypted password store, of course.

A client which caches credentials for the user over the long term should
be locking those credentials (whether public-key-based or
password-based) with a heavily-stretched password, to make offline
dictionary attacks expensive.

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

how does PAKE allow sharing of passwords between servers?  can't a
server willing to do a bunch of offline computation figure out the
client's password from its stored verifier?  this moves the offline
dictionary attack from the client to the server, but it would still
allow the server to recover the client's password, which would then
enable its reuse on different sites if the user thought it was ok to
share a password between services.

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

how strong is a PAKE for a generic network-based adversary?  how strong
is it when the server itself is the adversary?

At the CFRG meeting at IETF-89 earlier this month, there was very little
enthusiasm in the room for further discussion about PAKE.  this may just
be fatigue from the dragonfly discussion, though.

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

What about this proposal is different from SRP, which we already have?
Why not encourage more adoption of SRP and learn what the sticking
points are for that authentication mechanism?

My basic sense is that PAKE models are generally useful for one-shot or
limited-time use, as a bootstrapping step to something stronger, but not
as a regular, per-connection authentication mechanism.  I'd be happy to
be convinced that they're more generally useful, though :)

Regards,

	--dkg