Re: [auth48] AUTH48: RFC-to-be 9383 <draft-bar-cfrg-spake2plus-08> for your review

[Christopher Wood <[e-mail]>]

I do not feel strongly about the parenthetical. I defer to the RPC and their expertise here.

> 
> On May 1, 2023, at 8:26 PM, Lynne Bartholomew <[e-mail]> wrote:
> 
> Hi, Eliot, Tim, and Chris.
> 
> Tim and Chris, please advise regarding Eliot's question, bearing in mind that companion document RFC-to-be 9382 still has
> "(set up the protocol)" in its corresponding diagram.
> 
> In the meantime, it appears that the following is another good catch by Watson; we changed "therefore prevent" to "therefore prevents" in this document, as it appears to us that the meaning in this document is the same:
> 
>> From: Watson Ladd <[e-mail]>
>> Subject: One last nit (was Re: AUTH48: RFC-to-be 9382 <draft-irtf-cfrg-spake2-26> for your review)
>> Date: May 1, 2023 at 4:45:03 PM PDT
>> To: RFC Errata System <[e-mail]>
>> Cc: Benjamin Kaduk <[e-mail]>, Info <[e-mail]>, Станислав Смышляев <[e-mail]>, [e-mail]
>> 
>> Section 3.2
>> OLD:  "Including this list would ensure that both parties agree upon the
>>  same set of supported protocols and therefore prevent downgrade
>>  attacks."
>> 
>> NEW: "Including this list would ensure that both parties agree upon the
>>  same set of supported protocols and therefore prevents downgrade attacks"
>> 
>> NOTE: this changes the subject from the parties to the inclusion. The
>> difference is the s on prevents.
> 
> The latest files are posted here:
> 
>   https://www.rfc-editor.org/authors/rfc9383.txt
>   https://www.rfc-editor.org/authors/rfc9383.pdf
>   https://www.rfc-editor.org/authors/rfc9383.html
>   https://www.rfc-editor.org/authors/rfc9383.xml
>   https://www.rfc-editor.org/authors/rfc9383-diff.html
>   https://www.rfc-editor.org/authors/rfc9383-rfcdiff.html
>   https://www.rfc-editor.org/authors/rfc9383-auth48diff.html
>   https://www.rfc-editor.org/authors/rfc9383-lastdiff.html
>   https://www.rfc-editor.org/authors/rfc9383-lastrfcdiff.html
> 
>   https://www.rfc-editor.org/authors/rfc9383-xmldiff1.html
>   https://www.rfc-editor.org/authors/rfc9383-xmldiff2.html
> 
> Please let us know if we updated in error.
> 
> Thank you!
> 
> RFC Editor/lb
> 
> 
>> On May 1, 2023, at 4:59 PM, Independent Submissions Editor (Eliot Lear) <[e-mail]> wrote:
>> 
>> Lynn,
>> 
>> I think this was a good catch by Watson.  But now I wonder if that parenthetical is even needed.  The phrase is not used above, and it seems simply to clutter the diagram.  Could the authors respond on this point?
>> 
>> Eliot
>> 
>>> On 02.05.23 00:41, Lynne Bartholomew wrote:
>>> Dear Tim, Chris, and Eliot,
>>> 
>>> Per feedback from Watson Ladd re. companion document RFC-to-be 9382, we changed "(setup protocol)" to "(set up the protocol)" in the trace diagram in Section 3.1.  Please let us know any concerns.
>>> 
>>> The latest files are posted here.  Please refresh your browser:
>>> 
>>>   https://www.rfc-editor.org/authors/rfc9383.txt
>>>   https://www.rfc-editor.org/authors/rfc9383.pdf
>>>   https://www.rfc-editor.org/authors/rfc9383.html
>>>   https://www.rfc-editor.org/authors/rfc9383.xml
>>>   https://www.rfc-editor.org/authors/rfc9383-diff.html
>>>   https://www.rfc-editor.org/authors/rfc9383-rfcdiff.html
>>>   https://www.rfc-editor.org/authors/rfc9383-auth48diff.html
>>>   https://www.rfc-editor.org/authors/rfc9383-lastdiff.html
>>>   https://www.rfc-editor.org/authors/rfc9383-lastrfcdiff.html
>>> 
>>>   https://www.rfc-editor.org/authors/rfc9383-xmldiff1.html
>>>   https://www.rfc-editor.org/authors/rfc9383-xmldiff2.html
>>> 
>>> Thank you!
>>> 
>>> RFC Editor/lb
>>> 
>>>> On Apr 11, 2023, at 3:47 PM, Lynne Bartholomew <[e-mail]> wrote:
>>>> 
>>>> Hi, Eliot and Chris.  Thanks for the quick replies!
>>>> 
>>>> Eliot, thanks also for the clarifications.
>>>> 
>>>> Regarding the following:
>>>> 
>>>>>> I believe RFC 9383 is correct, and is how NIST refers to the curves.
>>>> I will pass this info. on (i.e., adding the hyphens in the "For P..." entries) to the folks working on RFC 9382.
>>>> 
>>>> 
>>>>>> I hope it got corrected in production, but 9282 had "Table Table 1" in Section 6
>>>> It was indeed fixed; RFC 9382 looks fine.
>>>> 
>>>> Thanks again!
>>>> 
>>>> RFC Editor/lb
>>>> 
>>>> 
>>>>> On Apr 11, 2023, at 3:32 PM, Christopher Wood <[e-mail]> wrote:
>>>>> 
>>>>> +1 to Elliot. P-256 with the hyphen is correct.
>>>>> 
>>>>>> On Apr 11, 2023, at 6:10 PM, Independent Submissions Editor (Eliot Lear) <[e-mail]> wrote:
>>>>>> 
>>>>>> 
>>>>>>> On 11.04.23 22:46, Lynne Bartholomew wrote:
>>>>>>> Hi, Eliot.
>>>>>>> 
>>>>>>> We have noted your approval on the AUTH48 status page:
>>>>>>> 
>>>>>>> https://www.rfc-editor.org/auth48/rfc9383
>>>>>>> 
>>>>>>> Please note that if we later pick up on any changes to any lines containing "seed" in either of these documents, we will ask the authors about such changes.
>>>>>> Ok.
>>>>>> 
>>>>>> 
>>>>>>> In the meantime, apologies, but we're not sure what "it may be good to reference such values" means in your note below.
>>>>>> Apologies.  What I meant was that the authors could have referenced the appropriate section of RFc 9382 instead of repeating the values.  Let me tell you all what fun it was to compare several long strings of numbers ;-)
>>>>>> 
>>>>>> As to this:
>>>>>> 
>>>>>>> rfc9382.txt:   For P256:
>>>>>>> rfc9382.txt:   For P384:
>>>>>>> rfc9382.txt:   For P521:
>>>>>>> rfc9383.txt:   For P-256:
>>>>>>> rfc9383.txt:   For P-384:
>>>>>>> rfc9383.txt:   For P-521:
>>>>>> I believe RFC 9383 is correct, and is how NIST refers to the curves.
>>>>>> 
>>>>>> Also, as an aside, I hope it got corrected in production, but 9282 had "Table Table 1" in Section 6 of https://www.rfc-editor.org/internet-drafts/draft-irtf-cfrg-spake2-26.txt.
>>>>>> 
>>>>>> Eliot
>>>>>> 
>> 
>