Re: [auth48] [irsg] AUTH48: RFC-to-be 9496 <draft-irtf-cfrg-ristretto255-decaf448-08> for your review

[Colin Perkins <[e-mail]>]

Hi,

RFC 5743 section 2.1 requires those statements in the abstract and 
introduction, separately to the boilerplate.
Colin

On 27 Oct 2023, at 11:58, Jack Grigg wrote:

> Thanks Colin.
>
> Relatedly, I note that the consensus attribute's boilerplate text is
> duplicative of the last paragraph of the Introduction. The latter was 
> added
> in February in response to your review (as well as an earlier request 
> to
> add IRTF required statements). Is it still necessary now that the 
> Status of
> This Memo section has the consensus boilerplate, or could that 
> paragraph be
> removed?
>
> For comparison, I note that the last paragraph of the Introduction to 
> RFC
> 9380 is equal to the first sentence of our final Introduction 
> paragraph,
> i.e. it omits the second sentence.
>
> Jack
>
> On Thu, Oct 26, 2023 at 8:33 PM Colin Perkins <[e-mail]> 
> wrote:
>
>> Hi,
>>
>> The consensus attribute does have meaning for the IRTF stream and 
>> selects
>> between two different versions of the boilerplate.
>>
>> https://www.rfc-editor.org/styleguide/headers-and-boilerplate/
>>
>> Colin
>>
>>
>> On 26 Oct 2023, at 4:22, Jack Grigg wrote:
>>
>> Hi,
>>
>> On Tue, Oct 24, 2023 at 10:22 AM Sandy Ginoza <[e-mail]> 
>> wrote:
>>
>>> Hi Authors,
>>>
>>> Jack, thank you for your reply - please send along comments and 
>>> updates
>>> from your review once complete.
>>>
>>
>> Apologies for the delay on this; I got COVID for the first time a few
>> weeks ago, and my "next week" was entirely too optimistic about how 
>> quickly
>> I'd recover. I'm about half-way through my final review, and will 
>> hopefully
>> complete it in the next few days.
>>
>> Part of my review process involved porting the RFC Editor changes to 
>> our
>> reference Markdown source code, and regenerating the XML from that 
>> with
>> mmark. I have found a few differences between what the RFC Editor
>> provided and what mmark generates; some of them are just formatting 
>> (or
>> generation of empty blocks), and some of them look like bugs or
>> unimplemented features in mmark (for which I am opening issues). 
>> There is
>> one point I am unclear on however, that I would like to clarify.
>>
>> The RFC Editor changed the document stream metadata from IETF to 
>> IRTF, and
>> also added the attribute consensus = "true". mmark only adds the 
>> consensus
>> attribute for documents in the IETF stream
>> <https://github.com/mmarkdown/mmark/blob/3d25d9375c96315e75624f8f5b9d814d870e35fe/render/xml/title.go#L46-L52> 
>> .
>> RFC 7991 doesn't say
>> <https://datatracker.ietf.org/doc/html/rfc7991#section-2.45.2> 
>> whether
>> the consensus attribute is stream-dependent, and points to RFC 7841,
>> which in an appendix
>> <https://datatracker.ietf.org/doc/html/rfc7841#appendix-A.2.2> 
>> appears to
>> indicate that consensus language can be present for IRFT stream 
>> documents.
>> Is it intended that the consensus attribute be used with IRTF stream
>> documents (i.e. is this a bug in mmark)?
>>
>>
>>>
>>> Authors, please review the document and let us know if any updates 
>>> are
>>> needed.
>>>
>>
>> Once my review is complete, I will reply here with both the generated 
>> XML,
>> and links to the GitHub repo with diffs of all formats.
>>
>> Cheers,
>> Jack
>>
>>
>>>
>>> Thank you,
>>> RFC Editor/sg
>>>
>>>> On Oct 13, 2023, at 10:36 PM, Jack Grigg <[e-mail]> 
>>>> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Thank you RFC Editor/sg/ap for your work! I will perform my final
>>> review next week, but in the interim I can respond to some of the 
>>> questions.
>>>>
>>>> For clarity, this email is NOT suggesting any immediate changes to 
>>>> the
>>> text (I will make my own suggestions after my review).
>>>>
>>>> On Sat, Oct 14, 2023 at 12:47 PM <[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] Please insert any keywords (beyond those that 
>>>> appear in
>>> the title) for use on https://www.rfc-editor.org/search. -->
>>>>
>>>>
>>>> 2) <!-- [rfced] Please ensure that the guidelines listed in Section 
>>>> 2.1
>>> of RFC 5743
>>>> have been adhered to in this document.  See
>>>> https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1.
>>>> -->
>>>>
>>>>
>>>> 3) <!-- [rfced] Please consider including a reference for "Discrete 
>>>> Log
>>> Hardness".
>>>> We do not see this phrase in RFCs and we did not find directly 
>>>> matching
>>> hits via
>>>> our general searches.  Is this the same as the "hardness of the
>>> discrete logarithm
>>>> problem"?
>>>>
>>>> Original:
>>>>    This means the group has a cofactor
>>>>    of 1, and all elements are equivalent from the perspective of
>>>>    Discrete Log Hardness.
>>>> -->
>>>>
>>>>
>>>> I think that "Discrete Log Hardness" and "hardness of the discrete
>>> logarithm problem" could be used interchangeably here.
>>>>
>>>>
>>>> 4) <!-- [rfced] We have updated the following for readability.  
>>>> Please
>>> review to
>>>> ensure we have not altered the meaning.
>>>>
>>>> Original:
>>>>    Edwards curves provide a number of implementation benefits for
>>>>    cryptography, such as complete addition formulas with no 
>>>> exceptional
>>>>    points and formulas among the fastest known for curve 
>>>> operations.
>>>>
>>>> Current:
>>>>    Edwards curves provide a number of implementation benefits for
>>>>    cryptography, such as complete addition formulas with no 
>>>> exceptional
>>>>    points and formulas known to be among the fastest for curve
>>>>    operations.
>>>> -->
>>>>
>>>>
>>>> 5) <!-- [rfced] Is "hash_to_curve" considered an algorithm? RFC 
>>>> 9380
>>> refers to
>>>> it as an encoding function.
>>>>
>>>> Original:
>>>>    In some contexts this property would be a weakness, but it is
>>>>    important in some contexts: in particular, it means that a
>>>>    combination of a cryptographic hash function and the element
>>>>    derivation function is suitable for use in algorithms such as
>>>>    hash_to_curve [draft-irtf-cfrg-hash-to-curve-16].
>>>> -->
>>>>
>>>>
>>>> A "hash-to-curve algorithm" is something we would have referred to,
>>> yes. This specific reference should be adjusted however, because the
>>> now-published RFC 9380 specifically constrains the definition of
>>> hash_to_curve, and in Appendix B defines hash_to_ristretto255 with 
>>> the same
>>> security properties and interface (and similarly for decaf448 in 
>>> Appendix
>>> C). I'll think about a suggestion during my review.
>>>>
>>>> Relatedly, I notice that RFC 9380 refers to an old version of this
>>> RFC-to-be. Once RFC 9496 is published, I presume that RFC 9380's 
>>> reference
>>> will be fixed? Their reference link is the one that implementers 
>>> will be
>>> following more (our reference here is effectively an informational
>>> backlink).
>>>>
>>>>
>>>> 6) <!-- [rfced] To what does "its" refer in the last sentence?
>>>>
>>>> Original (the paragraph is provided for context):
>>>>    Since ristretto255 is a prime-order group, every element except 
>>>> the
>>>>    identity is a generator, but for interoperability a canonical
>>>>    generator is selected, which can be internally represented by 
>>>> the
>>>>    Curve25519 basepoint, enabling reuse of existing precomputation 
>>>> for
>>>>    scalar multiplication.  This is its encoding as produced by the
>>>>    function specified in Section 4.3.2:
>>>> -->
>>>>
>>>>
>>>> "its" in the last sentence refers to "a canonical generator" in the
>>> previous sentence.
>>>>
>>>>
>>>> 7) <!-- [rfced] May we change "reflect" to "note" here?
>>>>
>>>> Original:
>>>>    Implementations SHOULD reflect that: the
>>>>    type representing an element of the group SHOULD be opaque to 
>>>> the
>>>>    caller, meaning they do not expose the underlying curve point or
>>>>    field elements.
>>>>
>>>> Suggested:
>>>>    Implementations SHOULD note that the
>>>>    type representing an element of the group SHOULD be opaque to 
>>>> the
>>>>    caller, meaning they do not expose the underlying curve point or
>>>>    field elements.
>>>> -->
>>>>
>>>>
>>>> I don't think so, assuming that "note" is meant in the sense "to 
>>>> take
>>> notice of". The SHOULD applies as-written to implementations, not
>>> implementers. An implementation reflects what its implementer has 
>>> noted.
>>>>
>>>> I will consider during my review whether in context 
>>>> "Implementations
>>> SHOULD reflect" or "Implementers SHOULD note" makes more sense.
>>>>
>>>>
>>>> 8) <!--[rfced] May we clarify "allowed operations" as follows?
>>>>
>>>> Original:
>>>>    The decoding
>>>>    function always returns a valid internal representation, or an 
>>>> error,
>>>>    and allowed operations on valid internal representations return 
>>>> valid
>>>>    internal representations.
>>>>
>>>> Perhaps:
>>>>    The decoding
>>>>    function always returns a valid internal representation, or an 
>>>> error,
>>>>    and operations that are allowed on valid internal 
>>>> representations
>>> return valid
>>>>    internal representations.
>>>> -->
>>>>
>>>>
>>>> 9) <!-- [rfced] FYI, we have alphabetized the references. Please 
>>>> let us
>>> know
>>>> of any objections.
>>>> -->
>>>>
>>>>
>>>> 10) <!-- [rfced] The sourcecode in Appendices A.1, A.2, and A.3 
>>>> extend
>>>> beyond the 69-character margin.  Please let us know how the lines 
>>>> may
>>>> be broken.
>>>> -->
>>>>
>>>>
>>>> As these are not actual source code with established parsing rules,
>>> breaking the lines must be done carefully to ensure that adjacent 
>>> test
>>> vectors are correctly separated. I'll make a suggestion to this 
>>> effect in
>>> my review.
>>>>
>>>>
>>>> 11) <!-- [rfced] Please review whether any of the notes in this 
>>>> document
>>>> should be in the <aside> element. It is defined as "a container for
>>>> content that is semantically less important or tangential to the
>>>> content that surrounds it" (
>>> https://authors.ietf.org/en/rfcxml-vocabulary#aside).
>>>> -->
>>>>
>>>>
>>>> 12) <!-- [rfced] Please review the "Inclusive Language" portion of 
>>>> the
>>> online
>>>> Style Guide <
>>> https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
>>>> and let us know if any changes are needed.
>>>>
>>>> For example, please consider whether "whitespace" should be 
>>>> updated.
>>>> -->
>>>>
>>>>
>>>> "Whitespace" here means any character that represents horizontal or
>>> vertical space in typography (
>>> https://en.wikipedia.org/wiki/Whitespace_character). To my knowledge
>>> there are no "positive or less harmful" connotations associated with 
>>> this
>>> term (unlike other historic terms of art in computer science), and I 
>>> don't
>>> know of another term that denotes the same set. But really all we 
>>> need here
>>> is a concise way to say "if you're copy-pasting these hex strings 
>>> into your
>>> code, any spaces, tabs, newlines, or whatever else the rendered 
>>> version of
>>> this RFC happens to put into those gaps can be ignored and must be 
>>> removed,
>>> and the position of them is irrelevant".
>>>>
>>>> Cheers,
>>>> Jack
>>>>
>>>>
>>>> Thank you.
>>>>
>>>> RFC Editor/sg/ap
>>>>
>>>>
>>>> On Oct 13, 2023, at 4:46 PM, [e-mail] wrote:
>>>>
>>>> *****IMPORTANT*****
>>>>
>>>> Updated 2023/10/13
>>>>
>>>> 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/rfc9496.xml
>>>>   https://www.rfc-editor.org/authors/rfc9496.html
>>>>   https://www.rfc-editor.org/authors/rfc9496.pdf
>>>>   https://www.rfc-editor.org/authors/rfc9496.txt
>>>>
>>>> Diff file of the text:
>>>>   https://www.rfc-editor.org/authors/rfc9496-diff.html
>>>>   https://www.rfc-editor.org/authors/rfc9496-rfcdiff.html (side by
>>> side)
>>>>
>>>> Diff of the XML:
>>>>   https://www.rfc-editor.org/authors/rfc9496-xmldiff1.html
>>>>
>>>>
>>>> Tracking progress
>>>> -----------------
>>>>
>>>> The details of the AUTH48 status of your document are here:
>>>>   https://www.rfc-editor.org/auth48/rfc9496
>>>>
>>>> Please let us know if you have any questions.
>>>>
>>>> Thank you for your cooperation,
>>>>
>>>> RFC Editor
>>>>
>>>> --------------------------------------
>>>> RFC9496 (draft-irtf-cfrg-ristretto255-decaf448-08)
>>>>
>>>> Title            : The ristretto255 and decaf448 Groups
>>>> Author(s)        : H. Valence, J. Grigg, M. Hamburg, I. Lovecruft, 
>>>> G.
>>> Tankersley, F. Valsorda
>>>> WG Chair(s)      :
>>>> Area Director(s) :
>>>>
>>>>
>>>
>>>