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

Lynne Bartholomew <lbartholomew@amsl.com> Tue, 02 May 2023 16:44 UTC

Return-Path: <lbartholomew@amsl.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E61C16B5B3; Tue, 2 May 2023 09:44:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.897
X-Spam-Level:
X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6DEGaizvHSQ; Tue, 2 May 2023 09:44:54 -0700 (PDT)
Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA785C16B5B2; Tue, 2 May 2023 09:44:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id AA7C8424B443; Tue, 2 May 2023 09:44:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eIi9yRt8MYI; Tue, 2 May 2023 09:44:50 -0700 (PDT)
Received: from smtpclient.apple (c-67-180-17-40.hsd1.ca.comcast.net [67.180.17.40]) by c8a.amsl.com (Postfix) with ESMTPSA id 85757424B441; Tue, 2 May 2023 09:44:50 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\))
From: Lynne Bartholomew <lbartholomew@amsl.com>
In-Reply-To: <B64380D7-2AA3-4DB7-9531-F35C2DD5545D@heapingbits.net>
Date: Tue, 02 May 2023 09:44:38 -0700
Cc: Tim Taubert <ttaubert=40apple.com@dmarc.ietf.org>, "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, auth48archive@rfc-editor.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0F99122C-8071-4CD3-9B9F-6BAE465C99A5@amsl.com>
References: <8C3BC6F2-32BC-4601-968C-0A0F414D65B0@amsl.com> <B64380D7-2AA3-4DB7-9531-F35C2DD5545D@heapingbits.net>
To: Christopher Wood <caw@heapingbits.net>, "Independent Submissions Editor (Eliot Lear)" <rfc-ise@rfc-editor.org>
X-Mailer: Apple Mail (2.3731.200.110.1.12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/wvYR2ND4IEKJNW4m2kdidffbHUU>
Subject: Re: [auth48] AUTH48: RFC-to-be 9383 <draft-bar-cfrg-spake2plus-08> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Tue, 02 May 2023 16:44:58 -0000

Hi, Chris and Eliot.

Chris, thanks for the note.  It now comes down to whether or not anyone is concerned that companion document RFC-to-be 9382 has the parenthetical but this document no longer does.

Eliot, would you prefer that the diagrams in question be consistent when it comes to "(set up the protocol)", or is it fine to leave both documents as they are in this regard?

Thanks again.

RFC Editor/lb

> On May 2, 2023, at 3:18 AM, Christopher Wood <caw@heapingbits.net> wrote:
> 
> 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 <lbartholomew@amsl.com> 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 <watsonbladd@gmail.com>
>>> 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 <rfc-editor@rfc-editor.org>
>>> Cc: Benjamin Kaduk <kaduk@mit.edu>, Info <irsg@irtf.org>, Станислав Смышляев <smyshsv@gmail.com>, auth48archive@rfc-editor.org
>>> 
>>> 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) <rfc-ise@rfc-editor.org> 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 <lbartholomew@amsl.com> 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 <caw@heapingbits.net> wrote:
>>>>>> 
>>>>>> +1 to Elliot. P-256 with the hyphen is correct.
>>>>>> 
>>>>>>> On Apr 11, 2023, at 6:10 PM, Independent Submissions Editor (Eliot Lear) <rfc-ise@rfc-editor.org> 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
>>>>>>> 
>>> 
>> 
>