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

[Colin Perkins <[e-mail]>]

Thanks - I’ll start the IRSG final poll.
Colin



On 25 Aug 2022, at 23:15, Leonid Reyzin wrote:

> No outstanding issues. Thanks!
>
> On Thu, Aug 25, 2022 at 5:25 PM Colin Perkins <[e-mail]> 
> wrote:
>
>> 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
>>
>>