Re: [CFRG] IRTF Chair review of draft-irtf-cfrg-vrf-12

[Leonid Reyzin <[e-mail]>]

Dear Colin,

Thank you for your feedback. We addressed all your comments. Specifically,
for Section 5.4.5, we explained that this algorithm MAY be used, and added
a considerable amount of rationale for its design, including the rationale
for the choice of bad_y2. For deciding which algorithm to use, we added a
paragraph to Section 1 that points to security differences among the
algorithms as addressed in Sections 3 and 7.

As far as the test vectors, the entire section is generated directly by the
reference implementation, which directly outputs xml2rfc version 3. The
reference implementation itself has been extensively debugged and tested
against other implementations of relevant components.

We uploaded the new version (-13) to
https://datatracker.ietf.org/doc/draft-irtf-cfrg-vrf/

Finally, regarding IPR disclosures, we are not aware of any IPR claims.

Thanks for your work,

 Leo


On Wed, Jun 15, 2022 at 9:28 AM Colin Perkins <[e-mail]> wrote:

> The CFRG chairs have requested that draft-irtf-cfrg-vrf-12 be published as
> an RFC on the IRTF stream. The IRTF publication process is described in RFC
> 5743, and comprises a review by the IRSG to ensure technical and editorial
> quality, followed by a check by the IESG to ensure the work does not
> conflict with IETF standards activities.
>
> As IRTF Chair, I perform an initial review of all drafts submitted for
> publication on the IRTF stream before sending them for detailed review by
> the IRSG. This note provides my review comments, for discussion.
>
> Authors, please can you also respond to this message to confirm that all
> necessary IPR disclosures, as described on https://irtf.org/policies/ipr,
> have been made?
>
> Result: Almost Ready
>
> RFC 5743 compliance: The draft follows the guidelines in RFC 5743
>
> Comments:
>
> Thank you for preparing this draft. On the whole, I found it clearly
> written and easy to follow. I have some minor questions for clarification,
> and a couple of nits to address:
>
>    -
>
>    Nit: I suggest to remove the §1.1 sub-heading, and to move the
>    sentence “This document represents the consensus of the Crypto Forum
>    Research Group (CFRG)” to follow the two paragraphs that currently comprise
>    Section 1.1.
>    -
>
>    Nit: RFC 8174 updates RFC 2119 and suggests a slightly different
>    phrasing for the key words section. Suggest updating to use that reference
>    instead of RFC 2119.
>    -
>
>    Section 5.4.5 defines bad_y2 =
>    2707385501144840649318225287225658788936804267575313519463743609750303402022.
>    It’s not clear why this particular value was chosen. The discussion at the
>    end of the section hints at an answer, but I wonder if it should be more
>    specific?
>    -
>
>    Section 5.4.5 says “For example, the following algorithm may be
>    used…”. This seems imprecise. How important is the choice of algorithm?
>    -
>
>    As a general point, I found that the draft clearly describes the
>    algorithms to be used, but was less clear in describing when to use each of
>    them, and what are the trade-offs between the different choices. It may be
>    worth expanding the Introduction a little to outline applicability of the
>    different options.
>    -
>
>    The appendix contains extensive test vectors. Has there been some test
>    performed to compare these with known-correct outputs, to make sure no
>    typos have been introduced when preparing the draft?
>
> Colin Perkins
> IRTF Chair
>