Hello,
I support adoption, will probably implement it, and definitely use it. As I mentioned at IETF 123, I do not think having multiple choices for basically the same thing is a wise and I think the choice the authors made to do SPAKE2+ was a mistake*. I would encourage paring this down to a balanced PAKE (CPace) and an asymmetric PAKE (OPAQUE). regards, Dan. * If a discrete logarithm for M is discovered then SPAKE2+ is broken. While I do not think there is a backdoor in the H2C-derived M in the draft, it is a high value target and a (unnecessary) weak point in a system. On 7/24/25 12:01 AM, Sean Turner wrote:
At IETF 122 & 123 we discussed draft-bmw-tls-pake13 [0]. The sense of room @ both sessions was that there was support for working on PAKEs in TLS. This email starts the WG adoption call for draft-bmw-tls-pake13. If you support adoption and are willing to review and contribute text, please send a message to the list. If you do not support adoption of this draft, please send a message to the list and indicate why. This call will close at 2359 UTC on 07 August 2025. Cheers, Deirdre, Joe, and Sean [0] https://datatracker.ietf.org/doc/draft-bmw-tls-pake13/ _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
-- "The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." -- Marcus Aurelius _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
