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

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 25 Nov 2021 07:47:10 -0600

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 <
[email-masked]> 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!
>
>
>
>

---

From: Colin Perkins <[email-masked]>
Date: Thu, 25 Nov 2021 23:18:59 +0000

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 <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> https://datatracker.ietf.org/doc/draft-irtf-cfrg-spake2/ <https://datatracker.ietf.org/doc/draft-irtf-cfrg-spake2/>
> 
> 
> 
> “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
> 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
> “Many of these applications predated methods to hash to elliptic curves being
> 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
> 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
> 
> With no pointer for “later”. I scanned the document for the string “symmetric”,
> _______________________________________________
> CFRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

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