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

Thanks, Spencer. I believe this draft is now ready for IESG conflict review, and will move it forward on Monday unless I hear objections.

Colin

> On 25 Nov 2021, at 13:47, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
> 
> 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 <noreply@ietf.org <mailto:noreply@ietf.org>> 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/ <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!
> 
> 
> 
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg

-- 
Colin Perkins
https://csperkins.org/