SPAKE2, a Password-Authenticated Key Exchange
draft-irtf-cfrg-spake2-26

I found this text in the Introduction to be helpful. 

“SPAKE2 was not selected as the result of the CFRG PAKE selection competition. However, given existing use of variants in Kerberos and other applications it was felt publication was beneficial.”

Perhaps it’s worth including in the Abstract as well, because it does explain why the document is being published in a way that’s not clear from the Abstract now. 

If that makes sense, perhaps it’s worth including the second sentence in this text from the Introduction, in the Abstract as well. 

“Many of these applications predated methods to hash to elliptic curves being available or predated the publication of the PAKEs that were chosen as an outcome of the PAKE selection competition. In cases where a symmetric PAKE is needed, and hashing onto an elliptic curve at protocol execution time is not available, SPAKE2 is useful.”

I’m obviously not a CFRG guy, so I don’t know what crypto people need to see first, but I’m surprised that section 3.2 doesn’t come before section 3.1. It does an excellent job of explaining how SPAKE2 works as a protocol at a higher level than 3.1.

One nit in 3.2 - I see 

"If this assignment of roles is not possible a symmetric variant described later MUST be used."

With no pointer for “later”. I scanned the document for the string “symmetric”, and I THINK I know where this text is pointing, but I’m guessing. 

While scanning, I noted this text:

"In addition M and N may be equal to have a symmetric variant."

This might be clearer as 

"If M and N are equal, this provides a symmetric variant."

Do the right thing, of course!

I am the document shepherd.