[TLS] First look at draft-bmw-tls-pake13-01.txt

[Eric Rescorla <[e-mail]>]

I gave this document an initial read. At a high level this seems like
a good start if the TLS WG is going to pursue PAKE bindings to TLS
1.3. With that said, given the longish history of PAKEs in TLS,
I'd like to be sure that we have critical mass for implementation,
so if we get to the point of an adoption call, I'd encourage
the chairs to be really sure there is enough interest in deployment
to justify this work.


A few detailed comments below...


It would be good to understand the deployment model here a little
better. S 4.2 prohibits the use of PAKEs with either PSKs or
Certificates, which I believe means that the only form of server
authentication is the PAKE. It seems like this is OK in some
circumstances, but it seems like if:

1. The client uses the same password on example.com and attacker.com
and
2. The attacker ever learns the password

Then the attacker can impersonate example.com to the user.

I would make two points here:

1. If you use a non-augmented PAKE, then things are very bad, but this
   draft doesn't seem to require an augmented PAKE.
1. Even with an augmented PAKE, you're still relying fairly heavily on
   the security of the PBKDF. If the user uses a common password, then
   the attacker can still brute force it.

I understand that this may not seem like that serious an attack
because if the attacker knows the password they can impersonate the
client to the server, but the other direction is also an issue because
it allows the attacker to lie to the client or to induce the client to
send them secrets (please reenter your SSN...). Assuming I'm not
wrong, then I think at minimum we need some kind of warning about this
case, and probably to to discourage it in contexts like the Web where
there is some other notion of identity. In particular, I think it
would be bad to have the following:

- Alice connects to example.com over HTTPS authenticated with a
  certificate and registers a password.
- Alice reconnects to example.com over HTTPS and uses a PAKE
  and this is treated as same origin with https://example.com

Note that this wouldn't necessarily be the case if you allowed the
combination of certificate-based auth and the PAKE, though that might
be problematic for other reasons.


Per S 4.2, if you use the PAKE then you don't do ECDHE at all
(i.e., you don't send key_share). This seems like it means
that you can't get any resistance to quantum computers unless
you have a PQ PAKE (which AFAIK SPAKE2+ is not). It seems like
if you also did the standard TLS 1.3 key establishment, then you
could use a PQ or PQ-hybrid algorithm and get protection against
harvest-now-decrypt-later attacks, though of course not against
impersonation if the attacker has a CRQC.

On a related topic, I note that the OPAQUE binding in
draft-sullivan-tls-opaque makes use of the TLS 1.3 key shares,
so I'm curious how you would do an OPAQUE binding here.

-Ekr