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

["Independent Submissions Editor (Eliot Lear)" <[e-mail]>]

Ok, I've reviewed the document.  I can confirm that the seeds in 9283 
are in fact currently the same as those listed in 
draft-irtf-cfrg-spake2-26.txt, but the RPC  should reconfirm this before 
releasing the RFCs.  Otherwise approved.

In the future, it may be good to *reference* such values...

Eliot


On 11.04.23 17:48, Lynne Bartholomew 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 inhttps://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
>>>>>