Re: [CFRG] [irsg] Spencer Dawkins' Yes on draft-irtf-cfrg-spake2-23: (with COMMENT)

[Spencer Dawkins at IETF <[e-mail]>]

Just to follow up,

Thank you, Watson, for addressing all my comments in -24. This draft is now
even more perfect.

Best,

Spencer

On Tue, Oct 26, 2021 at 9:02 AM Spencer Dawkins via Datatracker <
[e-mail]> wrote:

> Spencer Dawkins has entered the following ballot position for
> draft-irtf-cfrg-spake2-23: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-irtf-cfrg-spake2/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 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!
>
>
>
>