Subject: [Cfrg] Comments on draft-irtf-cfrg-vrf-01

From: Marek Jankowski <[email-masked]>
Date: Mon, 26 Mar 2018 07:55:43 -0700

Dear Goldberg, Reyzin, Rapadopoulos and Vcelak,
I have several comments and questions about the VRF RFC draft.

Section 2 - The last sentence reads "... is correct VRF hash of ...", but
should be "... is the correct VRF hash of ...".

Section 3.1 - The wording is somewhat confusing to me. specifically, the
second paragraph is a very formal security definition, while the following
one is much less formal, which makes this somewhat awkward to read. I
propose using the same style as section 3.2, which uses informal language
throughout the section (and in the second paragraph in particular).
Additionally, the use of "More precisely" in the second paragraph of
section 3.2 should also be adopted , as it makes it a lot clearer that the
first paragraph is a general description of the two following ones.

Section 5 - It would probably make for easier reading if, after describing
the security properties of EC-VRF, there was a reference to section 5.6 for
those needing full collision resistance and full uniqueness.
Moreover, the parameter description seems to require the size of the field
to be an even number of octets. This is, of course, not actually required,
as the instantiation with ED25519 in 5.5 shows. It should be explicitly
mentioned that 2n is the size of a field element in octets, rounded up.

Section 5.4.1 - It feels worthwhile to explicitly note that the two
hash_to_curve implementations are not compatible. Perhaps explicit domain
separation should be added.

Section 7.3 - It is possible to also consider deterministic nonce
generation, as in EdDSA.

The matter of domain separation in the context of EC is suggested (in a
TODO) in 5.4. Perhaps it should be added to the RSA-based scheme as well. I
can't think of a specific reason, but this makes for a good practice.

General question:
Does pi necessarily give alpha away? That is, in applications where alpha
needs to remain secret, does pi need to be kept secret as well? If not
necessarily, is this a property that the RFC guarantees, or maybe another
possible property for a specific scheme?

Thank you,
Marek.