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

[Colin Perkins <[e-mail]>]

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