>>This is possible, but you’d need to have the client and server negotiate > based on >>what they have. For example, if the server has a SRP verifier from the > current >>protocol, but the client has a stored PBKDF2 hash of the password for that > server, >>they cannot communicate and would need to pick a different cipher suite. I > am not >>sure how you can do this without revealing the existence of an account > under some >>circumstances. So this might be a situation where fewer protocol options > is better. > > Of course both sides have to agree on common protocol details: You could do > this by specifying that you want to use PAKE and refine in an extension a > set of schemes that you are capable of.
There's not much to negotiate. I would expend minimal energy on negotiating parameters. The server holds the verifiers, and they are set in stone. To get a verifier, the user needs to be pre-provisioned. Spend energy on keeping the identity private. If you want to go something cool, add an OTP as a second factor. There are two ways to do it based on the math around the verifiers (that I am aware). I have implementations for both in Crypto++, if interested. Jeff _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
