Re: [CFRG] [irsg] IRSG review request: draft-irtf-cfrg-vrf-13

[Mallory Knodel <[e-mail]>]

Yes-- thanks all good! Appreciate it, Leo,

-Mallory

On 8/25/22 2:34 PM, Colin Perkins wrote:
>
> Hi Leo, Mallory,
>
> Thanks for the update. Mallory, can you please confirm if the changes 
> address your review comments?
>
> Thanks,
> Colin
>
>
>
> On 28 Jul 2022, at 19:33, Leonid Reyzin wrote:
>
>     Dear Mallory,
>
>     Thank you so much for a careful review. Your review encouraged me
>     to go over Sections 3 and 7.1 with an eye toward readability by
>     nonexperts. I reworked them accordingly. The new draft is here
>     https://datatracker.ietf.org/doc/draft-irtf-cfrg-vrf/14/ and here
>     https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/1be656811c54003a442608e9c6eb537aeb96afb4.
>     Responses to specific items inline below.
>
>     Sincerely,
>
>      Leo
>
>     Leonid Reyzin
>     Professor, Boston University Computer Science
>
>
>     On Fri, Jul 15, 2022 at 2:22 PM Mallory Knodel <[e-mail]>
>     wrote:
>
>         Hi all,
>
>         I've done a review for the IRSG of this document. My comments
>         are below.
>         As a reminder I'm preserving the IRTF Chair's request for
>         review that
>         includes the purpose of the IRSG review stage:
>
>         On 6/16/22 7:41 AM, Colin Perkins wrote:
>         > ...at least one IRSG member to volunteer to provide a
>         detailed review of the draft, as follows:
>         >> IRSG reviewers should look for clear, cogent, and
>         consistent writing. An important aspect of the review is to
>         gain a critical reading from reviewers who are not subject
>         matter experts and, in the process, assure the document will
>         be accessible to those beyond the authoring research group.
>         Also, reviewers should assess whether sufficient editorial
>         and technical review has been conducted and the requirements
>         of this process document, such as those described
>         in IRTF-RFCs have been met. Finally, reviewers should check
>         that appropriate citations to related research literature have
>         been made.
>         My review does not include sections 4. and 5. because they are
>         primarily
>         describing VRF constructions, the accuracy of which I cannot
>         attest, and
>         therefore I recommend an expert review of these if one has not
>         already
>         been done, though it seems from the shepherd write up that at
>         least one
>         has been done.
>         >> The IRSG review often results in the document
>         being revised. Once the reviewer(s), authors, and shepherd
>         have converged on review comments, the shepherd starts
>         the IRSG Poll on whether the document should be published.
>
>         For what it's worth, I think even if none of the changes that
>         I have
>         suggested are accepted, though I hope they are helpful, that
>         the draft
>         be published. Please reach out if there are questions about my
>         suggested
>         changes; I would like to know which are not accepted.
>
>         Super interesting work. I learned a lot and was happy to
>         conduct this
>         review! First comments, then nits.
>
>         Comments:
>
>           * It might be useful to readers to at some point in the document
>         discuss why the two  VRFs were chosen to be described in
>         depth, versus
>         others. The shepherd writeup contains some of this information.
>
>
>     Added the following sentence to section 1:  The choices of VRFs
>     for inclusion into this document were based, in part, on synergy
>     with existing RFCs and commonly available implementations of
>     individual components that are used within the VRFs.
>
>
>           * Since sections 4. and 5. are both VRF constructions, you might
>         actually preserve the promise that you specify "several" VRFs by
>         restructuring the table of contents by creating a section on VRF
>         constructions and then make RSA-FDH-VRF and ECVRF
>         sub-sections. You
>         could give an introduction to the section that discusses why
>         you chose
>         these two but also gives the reader some overall sense of
>         where to go to
>         look at other documentation of comparable construction
>         specifications.
>
>
>     I think I prefer to keep them separate so as to avoid long section
>     numbers and deep nesting.
>
>     As far as comparable specifications, I am not sure what is
>     appropriate or expected. There are some referenced in the
>     "implementation status," but that section is to be removed, and is
>     very difficult to keep up to date, anyway. VRFs are gaining in
>     popularity, and thus whatever we write there will likely be
>     quickly out of date.
>
>
>           * Terminology section could be expanded to include
>         definitions of:
>         trustworthiness, adversarial, function, verifying among
>         perhaps others.
>
>
>     Eliminated the use of "trustworthy" by rephrasing; defined
>     "adversary", "adversarial", and "malicious". I want to draw a line
>     at not turning this document into Crypto 101, as writing a Crypto
>     101 document is a very different and highly involved task.
>
>           * Relatedly I get the sense that there are quite a few terms
>         of art
>         that are also regular words, like "bounded" that ideally should be
>         formally defined somewhere or the nuanced meaning that they
>         have (versus
>         the regular, everyday word) can get lost on a reader who is not a
>         subject matter expert. These could go in the terminology
>         section or they
>         can simply be described the first time they are used.
>
>
>     Cleaned up the jargon a bit in section 3; removed stuff that would
>     be meaningless to a nonspecialist while simultaneously unnecessary
>     for a specialist.
>
>
>           * Sometimes when "an adversary" is invoked, I think what is
>         meant is
>         that anyone, including adversaries, could perform or not
>         perform such
>         feats, eg 3.2 para 2.
>
>
>     Indeed. In cryptography, anyone is a potential adversary. But you
>     have to give it a name, so you can refer to it in the next
>     sentence and understand its role. It's a bit like the word "consumer".
>
>
>           * Question: in section 3.2 it's stated that trusted collision
>         resistance VRFs MUST NOT be used if key generation process
>         cannot be
>         trusted, but it seems to me as a lay reader that whether the key
>         generation process is trusted is the precise definition of
>         full versus
>         trusted collision resistance. I'm curious of the answer, but
>         also this
>         text really needs to be fixed to avoid confusion.
>
>
>
>     Full vs trusted collision resistance is a property of the VRF
>     algorithms as specified and does not depend on the application. In
>     contrast, whether the key generation can be trusted or not depends
>     on who is running the algorithms -- in other words, depends on the
>     application.
>
>     Rewrote those sections (and 7.1) to clarify.
>
>
>           * Is there an opportunity to expand on the type of attacks
>         described
>         in 3.3 para 3? "a variety of chosen inputs alpha'" is doing a
>         lot of
>         work and might not immediately be understood to represent the
>         threat of
>         brute force or rainbow table attacks, if that is indeed what
>         is meant here.
>
>
>
>     Here the adversary doesn't get to do brute force or rainbow table
>     attacks because it can't evaluate the VRF on its own, since it
>     doesn't know SK. But it may obtain other VRF input/output pairs
>     simply because the VRFs gets used somehow in the application.
>     Rephrased to clarify.
>
>           * I am missing something about "selective pseudorandomness"
>         being a
>         weaker security property when each time it is mentioned it
>         seems to be a
>         stronger security property, including the paragraph that
>         immediately
>         follows. Either the text it is incorrect or it is too opaque,
>         either way
>         should be fixed.
>
>
>     Rephrased. The selective security property holds only against the
>     adversary is more limited in what it can do. Hence it's a weaker
>     security property.
>
>           * Would the "malicious key generation" discussed in 3.4 for
>         unpredictability also have specific effects related to the other
>         properties just described as well, eg collision, uniqueness,
>         etc? It
>         seems like a cross-cutting consideration and if so perhaps a
>         restructure
>         would help readers conceptualise that a bit better.
>
>
>     Added an explanation as part of the restructuring
>
>
>           * To that point, section 7.1.2 also discusses this and the
>         relationship between the two sections is not entirely clear.
>         Are they
>         redundant?
>
>
>     Not quite. 7.1.2 addresses pseudorandomness, not unpredictability.
>     I added 7.1.3 to explain this.
>
>
>         Nits:
>
>           * Abstract | All mentions of "elliptic curves" should be
>         uncapitalized
>         unless part of a title (this seems to be the convention and
>         the only
>         instance currently is in the abstract).
>
>
>     Fixed
>
>           * Abstract | doc specifies "several" VRF constructions, but
>         actually
>         only presents two.
>
>
>     Removed "several". How many constructions we present depends on
>     how you count -- there are two main constructions, but they branch
>     into more via details specified in the ciphersuites.
>
>
>           * 3.1 para 1 | fixed VRF public key instead of "fixed public
>         VRF key"
>
>
>     Fixed here and elsewhere: "public VRF key" is now consistently
>     "VRF public key"
>
>
>           * 3.1 para 2 | the comma delimited list is hard to read and
>         suggest
>         instead you use alternative formatting like a indented list.
>
>
>      Turned into bulleted list
>
>
>           * 3.2 para 1 | "need to be" probably should be "are",
>         otherwise you're
>         defining an aspect of the specification it would seem.
>
>
>     Indeed. Rephrased the section consistently.
>
>
>           * 3.3 para 2 | any word ending in -ly should never be
>         hyphenated, eg
>         "adversarially chosen".
>
>
>     Fixed here and elsewhere
>
>
>           * 3.3 para 6 | "does not look" or "is not"? I get why
>         randomness is
>         merely an appearance to anyone but the Prover, but to the
>         Prover it is a
>         certainty, so it "is". Similarly in the following paragraph
>         "does not
>         look" could be "can be distinguished from a random value".
>
>
>     Rephrased to be more clear. Note that "does not look" is a
>     stronger statement than "is not", but agree that the phrasing was
>     confusing.
>
>           * 3.4 title | Some VRFs might be taken out of the heading
>         since it
>         seems that all of the properties you are describing are for
>         Some VRFs,
>         not all. If there is an important distinction here it might need
>         expanding in the text instead of the title.
>
>
>     Clarified at the top of section 3.
>
>           * 3.4 title | Is the word "malicious" important here or
>         could any key
>         generation experience this?
>
>     That's the term from the literature, so changing it does not seem
>     appropriate. However, "malicious" generally means "doing whatever
>     evil you feel like", which, of course, includes, as a possibility,
>     doing whatever benign parties would do. Added a defintion of
>     Malicious to 1.2.
>
>           * 7.1.1 para 1 | "stadnard" should be standard.
>
>     Fixed (actually, it should be neither because what we are defining
>     is not a standard; rephrased.)
>
>           * 7.4 para 1 | Isn't the "private VRF key" the secret key?
>         Seems this
>         might be an instance that departs from the uniform notation a bit.
>
>
>     Went through and made "VRF secret key" the default term everywhere
>     (except when referencing the RSA standard, which uses the term
>     "private key")
>
>
>           * 7.8 para 1 | Dislike extensive parentheticals, so suggest
>         making the
>         latter half of the first sentence its own sentence. (If the
>         point is
>         worth including, just include it).
>
>
>     Rephrased
>
>
>           * 7.8 para 1 | "four queries" which four what?
>
>
>     Clarified
>
>           * 7.8 para final | the reference in square brackets needs
>         link text.
>
>
>     Not sure what the problem is or there even is a problem -- that's
>     just how references to other documents appear when I use xml2rfc.
>     References to drafts and RFC all look like this throughout the
>     document.
>
>           * 7.10 para 1 | Capitalise the first letter of the first
>         sentence.
>
>
>     Fixed
>
>         With thanks,
>
>         -Mallory
>
>         --
>         Mallory Knodel
>         CTO, Center for Democracy and Technology
>         gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271
>         BD3C C780
>
-- 
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780