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
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
