>> TLS-pwd already supports both of these. It also supports ECC too, >> which is problematic with the current SRP protocol.
>In the language of the CFRG draft, TLS-pwd is “balanced” where SRP is “augmented”, >so they’re not really equivalent, correct? Correct. >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. I think there are many flavors out there that may be beneficial in specific use-cases. I envision that e.g. in the context of the IoT with very constrained devices (specific) PAKE schemes might be helpful. Having an ExtensionType & corresponding CipherSuites for each of them would be way too much. Best, Jörn
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
