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

[Colin Perkins <[e-mail]>]

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