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

[Colin Perkins <[e-mail]>]

Thanks, Mallory, that concludes the IRSG review.

The next stage in the publication process is the IRSG final poll. 
Authors, do you have any outstanding issues to resolve before the draft 
progresses?

Colin



On 25 Aug 2022, at 19:46, Mallory Knodel wrote:

> 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