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

[Mallory Knodel <[e-mail]>]

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.

  * 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.

  * Terminology section could be expanded to include definitions of: 
trustworthiness, adversarial, function, verifying among perhaps others.

  * 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.

  * 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.

  * 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.

  * 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.

  * 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.

  * 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.

  * To that point, section 7.1.2 also discusses this and the 
relationship between the two sections is not entirely clear. Are they 
redundant?

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

  * Abstract | doc specifies "several" VRF constructions, but actually 
only presents two.

  * 3.1 para 1 | fixed VRF public key instead of "fixed public VRF key"

  * 3.1 para 2 | the comma delimited list is hard to read and suggest 
instead you use alternative formatting like a indented list.

  * 3.2 para 1 | "need to be" probably should be "are", otherwise you're 
defining an aspect of the specification it would seem.

  * 3.3 para 2 | any word ending in -ly should never be hyphenated, eg 
"adversarially chosen".

  * 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".

  * 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.

  * 3.4 title | Is the word "malicious" important here or could any key 
generation experience this?

  * 7.1.1 para 1 | "stadnard" should be standard.

  * 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.

  * 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).

  * 7.8 para 1 | "four queries" which four what?

  * 7.8 para final | the reference in square brackets needs link text.

  * 7.10 para 1 | Capitalise the first letter of the first sentence.

With thanks,

-Mallory

-- 
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780