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

[Lynne Bartholomew <[e-mail]>]

Hi, Chris.  We've noted your approval:

   https://www.rfc-editor.org/auth48/rfc9383

Thank you!

RFC Editor/lb


> On Apr 11, 2023, at 9:32 AM, Christopher Wood <[e-mail]> wrote:
> 
> Thanks, all, for your work on this document. I approve publication with the changes in Tim’s PR.
> 
> Best,
> Chris 
> 
>> On Apr 11, 2023, at 11:49 AM, Lynne Bartholomew <[e-mail]> wrote:
>> 
>> Hi, Tim.
>> 
>> We have changed "intermediate" to "input" (for IKM) per your note below.  Thank you for pointing it out!
>> 
>> We have also left "(setup protocol)" as is in the trace diagram, per this note on <https://github.com/chris-wood/draft-bar-cfrg-spake2plus/pull/35>:  'I think we should leave this as "setup protocol". It describes a phase of the protocol, not an action.'
>> 
>> 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
>> 
>> We have noted your approval on the AUTH48 status page:
>> 
>>  https://www.rfc-editor.org/auth48/rfc9383
>> 
>> Thanks again for your help and attentiveness to this document!
>> 
>> RFC Editor/lb
>> 
>> 
>>> On Apr 11, 2023, at 5:16 AM, Tim Taubert <ttaubert=[e-mail]> wrote:
>>> 
>>> Alice,
>>> 
>>> Thank you for updating the draft files once more!
>>> 
>>>>> On Apr 7, 2023, at 20:48, Alice Russo <[e-mail]> wrote:
>>>> 
>>>> Tim,
>>>> 
>>>> Thanks for your reply. Updated Section 1 accordingly (minus the word 'area' which I had mistakenly added in my email). The revised files are here (please refresh):
>>>> https://www.rfc-editor.org/authors/rfc9383.html
>>>> https://www.rfc-editor.org/authors/rfc9383.txt
>>>> https://www.rfc-editor.org/authors/rfc9383.pdf
>>>> https://www.rfc-editor.org/authors/rfc9383.xml
>>>> 
>>>> This diff file shows all changes from the approved I-D:
>>>> https://www.rfc-editor.org/authors/rfc9383-diff.html
>>>> https://www.rfc-editor.org/authors/rfc9383-rfcdiff.html (side by side)
>>>> 
>>>> This diff file shows the changes made during AUTH48 thus far:
>>>> https://www.rfc-editor.org/authors/rfc9383-auth48diff.html
>>>> 
>>>> This diff file shows only the changes since the last posted version:
>>>> https://www.rfc-editor.org/authors/rfc9383-lastrfcdiff.html (side by side)
>>>> 
>>>> Regarding the items that overlap with 9382:
>>>> - Per your note in github:
>>>>> I think we should leave this as "setup protocol". It describes a phase of the protocol, not an action.
>>>> no change to "setup protocol". Will confirm with the authors of 9382.
>>>> - Open item re: IKM's expansion (#9 in https://mailarchive.ietf.org/arch/msg/auth48archive/UhnTFML-8Ns1LXCAaavjZS04-5o/)
>>>> 
>>> 
>>> The PR changes “intermediate” to “input”. I missed pointing that out, sorry. I agree that this should be “input key material”.
>>> 
>>> As far as I am concerned, this is the last open item before the RFC can be approved for publication. 
>>> 
>>> — Tim
>>> 
>>> 
>>>> We will wait to hear from you again and from your coauthors
>>>> before continuing the publication process. This page shows 
>>>> the AUTH48 status of your document:
>>>> https://www.rfc-editor.org/auth48/rfc9383
>>>> 
>>>> Thank you.
>>>> RFC Editor/ar
>>>> 
>>>>> On Apr 6, 2023, at 10:55 PM, Tim Taubert <ttaubert=[e-mail]> wrote:
>>>>> 
>>>>> Alice,
>>>>> 
>>>>> Thank you. I have updated the PR with the changes you suggested.
>>>>> 
>>>>>> On Apr 6, 2023, at 22:49, Alice Russo <[e-mail]> wrote:
>>>>>> 
>>>>>> Re: #2
>>>>>> Remains open; please let us know any keywords for this document (beyond those that appear in the title).
>>>>>> 
>>>>> 
>>>>> The keywords that appear in the title are, I think, sufficient.
>>>>> 
>>>>>> Re: #5
>>>>>> In your provided text, FYI we moved "for example" to the beginning of the sentence for readability. In addition, should it be rephrased as follows to clarify the constraints?
>>>>>> 
>>>>>> Current:
>>>>>> For example, a constraint may be physical proximity through a local
>>>>>> network or when initiation of the protocol requires a first
>>>>>> authentication factor.
>>>>>> 
>>>>>> Perhaps:
>>>>>> For example, a constraint may be when physical proximity through a local 
>>>>>> are network is required or when a first authentication factor is required
>>>>>> for initiation of the protocol.
>>>>>> 
>>>>> 
>>>>> This is a good suggestion. I updated the PR.
>>>>> 
>>>>>> 
>>>>>> Re: #14
>>>>>> In your provided text, FYI we changed "does" to "do", as the subject is plural (the choice, its parameters, and the distribution). Also, added "the" before "distribution". 
>>>>>> 
>>>>>> Current:
>>>>>> Since the choice of PBKDF, its
>>>>>> parameters for computing w0 and w1, and the distribution of w0 and w1
>>>>>> do not affect interoperability, the PBKDF is not included as part of
>>>>>> the ciphersuite.
>>>>>> 
>>>>> 
>>>>> Updated the PR with this suggestion as well.
>>>>> 
>>>>>> Re: #17 and #18
>>>>>> Thank you for providing the line breaks and indentation for the longer lines. We suggest reviewing that it has been updated as intended.
>>>>> 
>>>>> Reviewed the updates. They look good, thanks!
>>>>> 
>>>>> — Tim
>>>>> 
>>>>> 
>>>>>> We will wait to hear from you again and from your coauthor
>>>>>> before continuing the publication process. This page shows 
>>>>>> the AUTH48 status of your document:
>>>>>> https://www.rfc-editor.org/auth48/rfc9383
>>>>>> 
>>>>>> Thank you.
>>>>>> RFC Editor/ar
>>>>>> 
>>>>>>> On Apr 6, 2023, at 9:03 AM, Tim Taubert <ttaubert=[e-mail]> wrote:
>>>>>>> 
>>>>>>> Hi all,
>>>>>>> 
>>>>>>> Thanks for the great comments and suggestions! We submitted a new pull request which should address all draft feedback:
>>>>>>> 
>>>>>>> https://github.com/chris-wood/draft-bar-cfrg-spake2plus/pull/35
>>>>>>> 
>>>>>>> 
>>>>>>> — Tim
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On 4. Apr 2023, at 07:10, [e-mail] wrote:
>>>>>>>> 
>>>>>>>> Authors,
>>>>>>>> 
>>>>>>>> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
>>>>>>>> 
>>>>>>>> 1) <!-- [rfced] We updated the document title as follows, to define
>>>>>>>> "PAKE".  We also added "Protocol" per wording in the Abstract and
>>>>>>>> Introduction.  Please let us know any objections.
>>>>>>>> 
>>>>>>>> Original:
>>>>>>>> SPAKE2+, an Augmented PAKE
>>>>>>>> 
>>>>>>>> Currently:
>>>>>>>> SPAKE2+, an Augmented Password-Authenticated Key Exchange (PAKE)
>>>>>>>>                          Protocol -->
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the
>>>>>>>> title) for use on <https://www.rfc-editor.org/search>. -->
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 3) <!-- [rfced] Section 1:  Does "other party's" refer to the other
>>>>>>>> party or to the party that makes direct use of the password?  If
>>>>>>>> neither suggestion below is correct, please clarify this text.
>>>>>>>> 
>>>>>>>> Original (the previous sentence is included for context):
>>>>>>>> SPAKE2+
>>>>>>>> is an augmented PAKE protocol, as only one party makes direct use of
>>>>>>>> the password during the execution of the protocol. The other party
>>>>>>>> only needs a record corresponding to the other party's registration
>>>>>>>> at the time of the protocol execution instead of the password.
>>>>>>>> 
>>>>>>>> Suggestion A ("other party's" refers to the other party):
>>>>>>>> SPAKE2+
>>>>>>>> is an augmented PAKE protocol, as only one party makes direct use of
>>>>>>>> the password during the execution of the protocol. The other party
>>>>>>>> only needs a record corresponding to its own registration at the
>>>>>>>> time of the protocol execution instead of the password.
>>>>>>>> 
>>>>>>>> Suggestion B ("other party's" refers to the party that makes direct
>>>>>>>> use of the password):
>>>>>>>> SPAKE2+
>>>>>>>> is an augmented PAKE protocol, as only one party makes direct use of
>>>>>>>> the password during the execution of the protocol. The other party
>>>>>>>> only needs a record corresponding to the first party's registration
>>>>>>>> at the time of the protocol execution instead of the password. -->
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 4) <!-- [rfced] Sections 1 and 3:  We found the use of the word "which" in
>>>>>>>> these sentences confusing.  For example, in the first sentence
>>>>>>>> listed below, do balanced PAKEs never benefit from Password Hashing
>>>>>>>> Functions to the same extent (in which case a comma before "which"
>>>>>>>> would be correct), or do balanced PAKEs sometimes benefit from
>>>>>>>> Password Hashing Functions to the same extent (in which case "that"
>>>>>>>> would be correct)?  In the second sentence, does "which" apply to the
>>>>>>>> data or the identities?
>>>>>>>> 
>>>>>>>> If the suggested text is not correct, please provide clarifying text,
>>>>>>>> taking into account whether or not the intent is to indicate "all
>>>>>>>> cases" or "some cases".
>>>>>>>> 
>>>>>>>> Original:
>>>>>>>> The record cannot be used directly to
>>>>>>>> successfully run the protocol as a prover, making this protocol more
>>>>>>>> robust than balanced PAKEs which don't benefit from Password Hashing
>>>>>>>> Functions to the same extent.
>>>>>>>> ...
>>>>>>>> The parties may share additional data
>>>>>>>> (the context) separate from their identities which they may want to
>>>>>>>> include in the protocol transcript.
>>>>>>>> ...
>>>>>>>> One example of additional data
>>>>>>>> is a list of supported protocol versions if SPAKE2+ were used in a
>>>>>>>> higher-level protocol which negotiates the use of a particular PAKE.
>>>>>>>> 
>>>>>>>> Suggested ("all cases", "all cases", and "some cases"):
>>>>>>>> The record cannot be used directly to
>>>>>>>> successfully run the protocol as a prover, making this protocol more
>>>>>>>> robust than balanced PAKEs, which don't benefit from Password
>>>>>>>> Hashing Functions to the same extent.
>>>>>>>> ...
>>>>>>>> The parties may share additional data
>>>>>>>> (the context) separate from their identities, which they may want to
>>>>>>>> include in the protocol transcript.
>>>>>>>> ...
>>>>>>>> One example of additional data
>>>>>>>> is a list of supported protocol versions if SPAKE2+ were used in a
>>>>>>>> higher-level protocol that negotiates the use of a particular PAKE. -->
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 5) <!-- [rfced] Section 1:  This sentence does not parse.  Please
>>>>>>>> clarify the meaning of "consist in being in" and "or when".
>>>>>>>> 
>>>>>>>> Original:
>>>>>>>> Constraints may consist in being in physical proximity through a
>>>>>>>> local network or when initiation of the protocol requires a first
>>>>>>>> authentication factor. -->
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 6) <!-- [rfced] Section 3:  "fix a generate P" reads oddly.  Should
>>>>>>>> some words be added or removed?
>>>>>>>> 
>>>>>>>> Original (the next sentence is included for context):
>>>>>>>> We fix a generate P of (large) prime-order subgroup of G.  P is
>>>>>>>> specified in the document defining the group, and so we do not repeat
>>>>>>>> it here.
>>>>>>>> 
>>>>>>>> Possibly ("generated" instead of "generate" and clarifying the
>>>>>>>> meaning of "the document"):
>>>>>>>> We fix a generated point P of the (large) prime-order subgroup of G.
>>>>>>>> P will be specified in the document that defines the group, and so we
>>>>>>>> do not repeat it here. -->
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 7) <!--[rfced] FYI, we asked about "intermediate" in "IKM" in 
>>>>>>>> RFC-to-be 9382; see question #9 in the mail to the authors of that
>>>>>>>> document (https://mailarchive.ietf.org/arch/msg/auth48archive/UhnTFML-8Ns1LXCAaavjZS04-5o/).
>>>>>>>> We will check with you before making updates.
>>>>>>>> -->
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 8) <!--[rfced] FYI, we asked about "setup protocol" in RFC-to-be 9382;
>>>>>>>> see question #6 in the mail to the authors of that document
>>>>>>>> (https://mailarchive.ietf.org/arch/msg/auth48archive/UhnTFML-8Ns1LXCAaavjZS04-5o/).
>>>>>>>> We will check with you before making updates.
>>>>>>>> -->
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 9) <!-- [rfced] Please review the "type" attribute of each artwork
>>>>>>>> element in the XML file.  Should any of the artwork elements be
>>>>>>>> tagged as sourcecode?  Please see
>>>>>>>> <https://www.rfc-editor.org/materials/sourcecode-types.txt>.
>>>>>>>> For example, could some artwork be listed as sourcecode with
>>>>>>>> type="pseudocode" or - in Section 4 and Appendix C - "test-vectors"?
>>>>>>>> -->
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 10) <!-- [rfced] Sections 3.2 and 3.3:  Should "represented as the empty
>>>>>>>> octet string" be "represented as an empty octet string"?
>>>>>>>> 
>>>>>>>> Original:
>>>>>>>> If an identity is unknown at the time of computing w0s or w1s, its
>>>>>>>> length is given as zero and the identity itself is represented as the
>>>>>>>> empty octet string.
>>>>>>>> ...
>>>>>>>> If an identity is absent, its length is given as zero and the
>>>>>>>> identity itself is represented as the empty octet string.
>>>>>>>> 
>>>>>>>> Possibly:
>>>>>>>> If an identity is unknown at the time of computing w0s or w1s, its
>>>>>>>> length is given as zero and the identity itself is represented as an
>>>>>>>> empty octet string.
>>>>>>>> ...
>>>>>>>> If an identity is absent, its length is given as zero and the
>>>>>>>> identity itself is represented as an empty octet string. -->
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 11) <!-- [rfced] Section 3.3:  We found the use of "that" in this
>>>>>>>> sentence confusing.  Are Z and V always shared as common values,
>>>>>>>> or only sometimes?
>>>>>>>> 
>>>>>>>> Original:
>>>>>>>> Both participants compute Z and V that are now shared as common
>>>>>>>> values.
>>>>>>>> 
>>>>>>>> Possibly (Z and V are always shared after both participants compute
>>>>>>>> them):
>>>>>>>> Both participants compute Z and V; Z and V are then shared as common
>>>>>>>> values. -->
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 12) <!-- [rfced] Section 3.3:  To what does "that which" refer in this
>>>>>>>> sentence?  If the suggested text is not correct, please provide
>>>>>>>> clarifying text.
>>>>>>>> 
>>>>>>>> Original:
>>>>>>>> Key
>>>>>>>> confirmation verification requires recomputation of confirmP or
>>>>>>>> confirmV and checking for equality against that which was received.
>>>>>>>> 
>>>>>>>> Suggested:
>>>>>>>> Key
>>>>>>>> confirmation verification requires recomputation of confirmP or
>>>>>>>> confirmV and checking for equality against the data that was
>>>>>>>> received. -->
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 13) <!-- [rfced] Section 3.4:  We expanded "AEAD" as "Authenticated
>>>>>>>> Encryption with Associated Data".  If this is incorrect, please
>>>>>>>> provide the correct expansion.
>>>>>>>> 
>>>>>>>> Original:
>>>>>>>> For example, applications
>>>>>>>> MAY derive one or more AEAD keys and nonces from K_shared for
>>>>>>>> subsequent application data encryption.
>>>>>>>> 
>>>>>>>> Currently:
>>>>>>>> For example, applications
>>>>>>>> MAY derive one or more Authenticated Encryption with Associated Data
>>>>>>>> (AEAD) keys and nonces from K_shared for subsequent application data
>>>>>>>> encryption. -->
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 14) <!-- [rfced] Section 4:  Does "distributing" refer to w0 and w1, or
>>>>>>>> something else?
>>>>>>>> 
>>>>>>>> Original:
>>>>>>>> Since the choice of PBKDF and
>>>>>>>> its parameters for computing w0 and w1 and distributing does not
>>>>>>>> affect interoperability, the PBKDF is not included as part of the
>>>>>>>> ciphersuite.
>>>>>>>> 
>>>>>>>> Possibly:
>>>>>>>> Since the choice of PBKDF and
>>>>>>>> its parameters for computing and distributing w0 and w1 does not
>>>>>>>> affect interoperability, the PBKDF is not included as part of the
>>>>>>>> ciphersuite. -->
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 15) <!-- [rfced] Table 1:  We do not see "SHA512", "SHA-512", or "512"
>>>>>>>> in RFC 5869.  Will these citations in this table be clear to readers?
>>>>>>>> 
>>>>>>>> We have the same question for SHA256, and SHA512; we do not see them
>>>>>>>> listed in RFC 2104. -->
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 16) <!-- [rfced] Appendices A.1 and A.2:  "behavior consists of" reads
>>>>>>>> oddly in these sentences.  If the suggested text is not correct,
>>>>>>>> please clarify.
>>>>>>>> 
>>>>>>>> Original:
>>>>>>>> The Prover's behavior consists of two functions, ProverInit and
>>>>>>>> ProverFinish, which are described below.
>>>>>>>> ...
>>>>>>>> The Verifier's behavior consists of a single function,
>>>>>>>> VerifierFinish, which is described below.
>>>>>>>> 
>>>>>>>> Suggested:
>>>>>>>> The Prover's process involves two functions, ProverInit and
>>>>>>>> ProverFinish, which are described below.
>>>>>>>> ...
>>>>>>>> The Verifier's process involves a single function, VerifierFinish,
>>>>>>>> which is described below. -->
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 17) <!-- [rfced] Appendix A.3: FYI, due to the line-length limitation, 
>>>>>>>> we have added a line break as follows. (The subsequent line is 
>>>>>>>> indented 2 characters; similar indentation is used in RFC 8805.) 
>>>>>>>> Please let us know if you prefer otherwise.
>>>>>>>> 
>>>>>>>> Original:                                                                           
>>>>>>>> def ComputeTranscript(Context, idProver, idVerifier, shareP, shareV, Z, V, w0):
>>>>>>>> 
>>>>>>>> Current:
>>>>>>>> def ComputeTranscript(Context, idProver, idVerifier, shareP, shareV,
>>>>>>>> Z, V, w0):
>>>>>>>> 
>>>>>>>> Also, please let us know if you'd like to add a sentence such as
>>>>>>>> "Line breaks have been added due to line-length limitations"
>>>>>>>> (as used in RFC 7790 and other documents).
>>>>>>>> -->
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 18) <!--[rfced] Appendix A.5: Similar to above, may we add a line break
>>>>>>>> (in 2 instances) so that this artwork is not "outdented" into the 
>>>>>>>> left margin in the text output?  To summarize line-length limitations:
>>>>>>>> * 72 characters for artwork elements. (Note: in the text output, 
>>>>>>>> the renderer will "outdent" into the left margin for artwork 
>>>>>>>> that is over 69 characters.)
>>>>>>>> * 69 characters for sourcecode elements.  
>>>>>>>> 
>>>>>>>> Original (2 instances):
>>>>>>>> TT = ComputeTranscript(Context, idProver, idVerifier, X, Y, Z, V, w0)
>>>>>>>> 
>>>>>>>> Perhaps:
>>>>>>>> TT = ComputeTranscript(Context, idProver, idVerifier, X, Y, Z, 
>>>>>>>>  V, w0)
>>>>>>>> -->
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 19) <!-- [rfced] Appendix B:  We found "the table below" in this
>>>>>>>> sentence confusing, as there isn't a table below this text.
>>>>>>>> We find '"1.3.132.0.35 point generation seed (M)" for P-512'
>>>>>>>> confusing as well, because we see 1.3.132.0.35 associated with P521
>>>>>>>> ("For P521:") in Section 4.
>>>>>>>> 
>>>>>>>> (We also see 1.3.132.0.35 associated with P521 on
>>>>>>>> <http://www.oid-info.com/
>>>>>>>> cgi-bin/display?oid=1.3.132.0.35&action=display> and in RFC 5480.)
>>>>>>>> 
>>>>>>>> May we change "table" to "Python snippet", per the paragraph just
>>>>>>>> before the Python snippet?
>>>>>>>> Should either P-512 or P521 (but not both) be used to refer to
>>>>>>>> 1.3.132.0.35?
>>>>>>>> 
>>>>>>>> Original:
>>>>>>>> For each curve in the table below, we construct a string using the
>>>>>>>> curve OID from [RFC5480] (as an ASCII string) or its name, combined
>>>>>>>> with the needed constant, for instance "1.3.132.0.35 point
>>>>>>>> generation seed (M)" for P-512.
>>>>>>>> 
>>>>>>>> Possibly:
>>>>>>>> For each curve in the Python snippet below, we construct a string
>>>>>>>> using the curve OID from [RFC5480] (as an ASCII string) or its name,
>>>>>>>> combined with the needed constant - for instance, "1.3.132.0.35 point
>>>>>>>> generation seed (M)" for P521. -->
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 20) <!--[rfced] Appendix C: FYI, the one large artwork element has been 
>>>>>>>> separated, as there seems to be 7 vectors. Please let us know if you 
>>>>>>>> prefer otherwise.   
>>>>>>>> -->
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 21) <!-- [rfced] Please review the "Inclusive Language" portion of the
>>>>>>>> online Style Guide at <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
>>>>>>>> and let us know if any changes are needed.
>>>>>>>> 
>>>>>>>> Note that our script did not flag any words in particular, but this
>>>>>>>> should still be reviewed as a best practice. -->
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 22) <!-- [rfced] The following term appears to be used inconsistently in
>>>>>>>> this document.  Please let us know which form is preferred.
>>>>>>>> 
>>>>>>>> Password Hashing Function / password hash function -->
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Thank you.
>>>>>>>> 
>>>>>>>> RFC Editor/ar/lb
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Apr 3, 2023, [e-mail] wrote:
>>>>>>>> 
>>>>>>>> *****IMPORTANT*****
>>>>>>>> 
>>>>>>>> Updated 2023/04/03
>>>>>>>> 
>>>>>>>> RFC Author(s):
>>>>>>>> --------------
>>>>>>>> 
>>>>>>>> Instructions for Completing AUTH48
>>>>>>>> 
>>>>>>>> Your document has now entered AUTH48.  Once it has been reviewed and 
>>>>>>>> approved by you and all coauthors, it will be published as an RFC.  
>>>>>>>> If an author is no longer available, there are several remedies 
>>>>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>>>>>>>> 
>>>>>>>> You and you coauthors are responsible for engaging other parties 
>>>>>>>> (e.g., Contributors or Working Group) as necessary before providing 
>>>>>>>> your approval.
>>>>>>>> 
>>>>>>>> Planning your review 
>>>>>>>> ---------------------
>>>>>>>> 
>>>>>>>> Please review the following aspects of your document:
>>>>>>>> 
>>>>>>>> *  RFC Editor questions
>>>>>>>> 
>>>>>>>> Please review and resolve any questions raised by the RFC Editor 
>>>>>>>> that have been included in the XML file as comments marked as 
>>>>>>>> follows:
>>>>>>>> 
>>>>>>>> <!-- [rfced] ... -->
>>>>>>>> 
>>>>>>>> These questions will also be sent in a subsequent email.
>>>>>>>> 
>>>>>>>> *  Changes submitted by coauthors 
>>>>>>>> 
>>>>>>>> Please ensure that you review any changes submitted by your 
>>>>>>>> coauthors.  We assume that if you do not speak up that you 
>>>>>>>> agree to changes submitted by your coauthors.
>>>>>>>> 
>>>>>>>> *  Content 
>>>>>>>> 
>>>>>>>> Please review the full content of the document, as this cannot 
>>>>>>>> change once the RFC is published.  Please pay particular attention to:
>>>>>>>> - IANA considerations updates (if applicable)
>>>>>>>> - contact information
>>>>>>>> - references
>>>>>>>> 
>>>>>>>> *  Copyright notices and legends
>>>>>>>> 
>>>>>>>> Please review the copyright notice and legends as defined in
>>>>>>>> RFC 5378 and the Trust Legal Provisions 
>>>>>>>> (TLP – https://trustee.ietf.org/license-info/).
>>>>>>>> 
>>>>>>>> *  Semantic markup
>>>>>>>> 
>>>>>>>> Please review the markup in the XML file to ensure that elements of  
>>>>>>>> content are correctly tagged.  For example, ensure that <sourcecode> 
>>>>>>>> and <artwork> are set correctly.  See details at 
>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>.
>>>>>>>> 
>>>>>>>> *  Formatted output
>>>>>>>> 
>>>>>>>> Please review the PDF, HTML, and TXT files to ensure that the 
>>>>>>>> formatted output, as generated from the markup in the XML file, is 
>>>>>>>> reasonable.  Please note that the TXT will have formatting 
>>>>>>>> limitations compared to the PDF and HTML.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Submitting changes
>>>>>>>> ------------------
>>>>>>>> 
>>>>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all 
>>>>>>>> the parties CCed on this message need to see your changes. The parties 
>>>>>>>> include:
>>>>>>>> 
>>>>>>>> *  your coauthors
>>>>>>>> 
>>>>>>>> *  [e-mail] (the RPC team)
>>>>>>>> 
>>>>>>>> *  other document participants, depending on the stream (e.g., 
>>>>>>>> IETF Stream participants are your working group chairs, the 
>>>>>>>> responsible ADs, and the document shepherd).
>>>>>>>> 
>>>>>>>> *  [e-mail], which is a new archival mailing list 
>>>>>>>> to preserve AUTH48 conversations; it is not an active discussion 
>>>>>>>> list:
>>>>>>>> 
>>>>>>>> *  More info:
>>>>>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>>>>>>>> 
>>>>>>>> *  The archive itself:
>>>>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/
>>>>>>>> 
>>>>>>>> *  Note: If only absolutely necessary, you may temporarily opt out 
>>>>>>>> of the archiving of messages (e.g., to discuss a sensitive matter).
>>>>>>>> If needed, please add a note at the top of the message that you 
>>>>>>>> have dropped the address. When the discussion is concluded, 
>>>>>>>> [e-mail] will be re-added to the CC list and 
>>>>>>>> its addition will be noted at the top of the message. 
>>>>>>>> 
>>>>>>>> You may submit your changes in one of two ways:
>>>>>>>> 
>>>>>>>> An update to the provided XML file
>>>>>>>> — OR —
>>>>>>>> An explicit list of changes in this format
>>>>>>>> 
>>>>>>>> Section # (or indicate Global)
>>>>>>>> 
>>>>>>>> OLD:
>>>>>>>> old text
>>>>>>>> 
>>>>>>>> NEW:
>>>>>>>> new text
>>>>>>>> 
>>>>>>>> You do not need to reply with both an updated XML file and an explicit 
>>>>>>>> list of changes, as either form is sufficient.
>>>>>>>> 
>>>>>>>> We will ask a stream manager to review and approve any changes that seem
>>>>>>>> beyond editorial in nature, e.g., addition of new text, deletion of text, 
>>>>>>>> and technical changes.  Information about stream managers can be found in 
>>>>>>>> the FAQ.  Editorial changes do not require approval from a stream manager.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Approving for publication
>>>>>>>> --------------------------
>>>>>>>> 
>>>>>>>> To approve your RFC for publication, please reply to this email stating
>>>>>>>> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
>>>>>>>> as all the parties CCed on this message need to see your approval.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Files 
>>>>>>>> -----
>>>>>>>> 
>>>>>>>> The files are available here:
>>>>>>>> https://www.rfc-editor.org/authors/rfc9383.xml
>>>>>>>> https://www.rfc-editor.org/authors/rfc9383.html
>>>>>>>> https://www.rfc-editor.org/authors/rfc9383.pdf
>>>>>>>> https://www.rfc-editor.org/authors/rfc9383.txt
>>>>>>>> 
>>>>>>>> Diff file of the text:
>>>>>>>> https://www.rfc-editor.org/authors/rfc9383-diff.html
>>>>>>>> https://www.rfc-editor.org/authors/rfc9383-rfcdiff.html (side by side)
>>>>>>>> 
>>>>>>>> Diff of the XML: 
>>>>>>>> https://www.rfc-editor.org/authors/rfc9383-xmldiff1.html
>>>>>>>> 
>>>>>>>> Tracking progress
>>>>>>>> -----------------
>>>>>>>> 
>>>>>>>> The details of the AUTH48 status of your document are here:
>>>>>>>> https://www.rfc-editor.org/auth48/rfc9383
>>>>>>>> 
>>>>>>>> Please let us know if you have any questions.  
>>>>>>>> 
>>>>>>>> Thank you for your cooperation,
>>>>>>>> 
>>>>>>>> RFC Editor
>>>>>>>> 
>>>>>>>> --------------------------------------
>>>>>>>> RFC9383 (draft-bar-cfrg-spake2plus-08)
>>>>>>>> 
>>>>>>>> Title            : SPAKE2+, an Augmented PAKE
>>>>>>>> Author(s)        : T. Taubert, C.A. Wood
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>