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

Lynne Bartholomew <lbartholomew@amsl.com> Tue, 02 May 2023 00:26 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 1B711C151B30; Mon, 1 May 2023 17:26:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-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 fS5IqcXboemT; Mon, 1 May 2023 17:26:38 -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 9F970C15198C; Mon, 1 May 2023 17:26:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 8E24A424CD02; Mon, 1 May 2023 17:26:38 -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 B2GQ8OX3HBPI; Mon, 1 May 2023 17:26:38 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2601:646:8b00:6b80:d522:c19f:e0da:255f]) by c8a.amsl.com (Postfix) with ESMTPSA id 67EA7424CD01; Mon, 1 May 2023 17:26:38 -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: <2cc1377f-0fac-c61a-3943-c686cfcedfda@rfc-editor.org>
Date: Mon, 01 May 2023 17:26:27 -0700
Cc: "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, auth48archive@rfc-editor.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <8C3BC6F2-32BC-4601-968C-0A0F414D65B0@amsl.com>
References: <db11cb98-04d4-601d-7d61-799a88bd9410@rfc-editor.org> <DE8548BF-FDDD-4FA8-850F-6DAEEA8928CE@heapingbits.net> <DCFFBEFC-524B-4289-AD35-78CB0D8422B4@amsl.com> <001796C2-CFCA-490D-826B-F61EACAC35DD@amsl.com> <2cc1377f-0fac-c61a-3943-c686cfcedfda@rfc-editor.org>
To: "Independent Submissions Editor (Eliot Lear)" <rfc-ise@rfc-editor.org>, Tim Taubert <ttaubert=40apple.com@dmarc.ietf.org>, Christopher Wood <caw@heapingbits.net>
X-Mailer: Apple Mail (2.3731.200.110.1.12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/7opuB-9cvjjAbwNM6u6P2RbM1P4>
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 00:26:43 -0000

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
>>>>> 
>