Re: [CFRG] Last call for draft-irtf-cfrg-vrf-09

["Kaliski, Burt" <[e-mail]>]

CFRG,



Following are some additional comments on draft-irtf-cfrg-vrf-09.



In general, the draft is well written and is effective in translating research concepts into an implementable specification.  The reuse of related techniques is helpful for interoperability.



The changes I suggest below are intended to clarify the specification, explain how certain error conditions are handled, and provide additional rationale for design choices.  None of the changes would affect the values computed by the VRFs.



I have not checked the test vectors.



I think the draft is ready for publication as an RFC once the comments already submitted in response to the last call are addressed, and modulo the comments offered here.



Thanks for the opportunity to review.  -- Burt



Technical Comments



T1. General: The specification frequently computes one-octet constants as an explicit algorithm step, e.g., "one_string = 0x01 = I2OSP(1, 1), a single octet with value 1".  Suggest defining the notation "0x" as in [RFC8017] and then using constants such as 0x01 directly in the algorithms rather than computing them, to avoid the superfluous steps. (The ECVRF algorithms use int_to_string which is suite-specific, but the single-octet output is the same for all suites.)



T2. Sec. 4, "Parameters used:" / "K - RSA private key": Suggest to add note that representation of K is implementation-dependent



T3. Sec. 4.3, step 2: Suggest adding error handling for the case that s >= n, in which case RSAVP1 will return "signature representative out of range" and the algorithm should output "INVALID"



T4. Sec. 4.3, step 3: Suggest adding error handling for the case that m >= 2^(8(k-1)), in which case I2OSP will return "integer too large" and the algorithm should output "INVALID".  Alternatively, instead of computing EM from m and comparing EM to EM', compute m' from EM' (as m' = OS2IP(EM')) and compare m to m'



T5. Sec. 5, "Fixed options" / "2n": Suggest adding an explanation why n is introduced this way. Based on the security analysis in [PWHVNRG17], n appears to correspond to the security level $\ell$, as both are the lengths of the challenge c (in octets vs. bits). It's not clear why the parameter n is defined here in terms of the length of a field element, rather than the size of group G. Although the security level is affected by the size of the field, it is not necessarily related to the length in octets of a field element (if this is understood to be the length if the octet string representing the field element, which may be implementation-defined). Also, the choice of field is not discussed outside this section of the document, although it is implied by the selection of curve parameters elsewhere. Suggest instead to introduce a new parameter such as cLen for the length in octets of the challenge c, and then in the security considerations, comment on the relationship between cLen, qLen, hash function output sizes, and security levels, much as is done in [PWHVNRG17].



T6. Sec. 5, "Fixed options:": Suggest adding ECVRF_hash_points as another fixed option after ECVRF_nonce_generation. (See comment below regarding the name of this technique.)



T7. Sec. 5.4.1.1, "Fixed option:" / "arbitrary_string_to_point" (and elsewhere):  The term "arbitrary" is a misnomer in that it is applied to a string that has already been hashed. Moreover, one of the two options supported for this function in Sec. 5.5 requires the string to be exactly 32 octets, and the other requires it to be at least 32 octets (in a suite that uses SHA-512, so the string will be exactly 64 octets). This contrasts with [PWHVNRG17]'s idea in Appendix A of "a hash function H1 that maps arbitrary-length strings to points on an elliptic curve". Indeed, the "hash to curve" functions in the document are the actual "arbitrary string to point" mappings. One possible solution would be to replace "arbitrary_string_to_point" with a newly defined "encode", following the model given by 5.4.1.2. "string_to_hash" would be computed as "suite_string || one_string || PK_string || alpha_string || ctr_string || zero_string", i.e., step 6B without the hashing, and passed to "encode". Instantiations of the "encode" option would be defined in Sec. 5.5.

An instantiation would include both the hashing and the existing conversion of the hash value to an elliptic curve point.



T8. Sec. 5.4.2: After "not compatible with each other", suggest adding "and are intended for specific suite(s)".



T9. Sec. 5.4.2.1 (also 5.4.2.2), "Output:" / "k": Suggest adding "nonce" before "an integer" to clarify purpose of k.



T10. Sec. 5.4.2.1, next to last para: Suggest adding a note that qlen, the length in bits of q in RFC6979, is not to be confused with qLen, the length in octets of q in this document.



T11. Sec. 5.4.3 (and elsewhere): Suggest redefining "ECVRF_hash_points" as "ECVRF_challenge_generation", limiting to four inputs (H, Gamma, U, and V), and labeling output as "challenge value" rather than "hash value". Rationale: ECVRF_hash_points is only used in this document for mapping the four specified inputs to the challenge c, so it is similar to ECVRF_nonce_generation in its limited purpose. The suggested change does not affect the value computed by the function on the specified inputs, only the way the function is specified.  The benefit of the change is that it simplifies implementation. In particular, implementations only need to be able to handle four points, not an arbitrary number M. Calls to the algorithm would need to be updated similarly. (If the function is not redefined as suggested here, then a note should be added to indicate that implementations MUST be able to handle the case M = 4; other cases are optional.)



T12. Sec. 7.6: Suggest moving the final sentence to its own section, titled "Dependence of challenge on generator and public key". The sentence explains why the challenge c still depends on all six points (B, H, Y, Gamma, U, and V) as per the formal specification in [PWHVNRG17], rather than just the four points input to ECVRF_hash_points. This discussion is important from a security proof perspective and it is separate from the prehashing considerations. Suggest adding "via the point H" to the end of the sentence.



Editorial Comments



E1. Sec. 1.1, para 1, line 3: "with corresponding" --> "with the corresponding"



E2. Sec. 1.1, para 2, line 2: "on data" --> "of data"?



E3. Sec. 2, last para, line 3: "the VRF also comes" --> "the VRFs defined in this document also come" (to match the model discussed in the prior paras where beta can be derived from pi, and to recognize that there are multiple VRFs in the document)



E4. Sec. 3.1, para 3, line 3: "it must only hold if" --> "it is only required to hold if" (see next)



E5. Sec. 3.2, para 3, line 3: "it holds only if" --> "it is only required to hold if" (to clarify that the property may also hold if the condition is not

met)



E6. Sec. 3.3, next to last para, line 2: "knows the valid VRF proof" --> "knows a valid VRF proof" (ECVRF has multiple valid proofs, one for each k)



E7. Sec. 4, para 2, line 3: "parametrized" --> "parameterized"



E8. Sec. 4, "Primitives used:" / "RSASP1": "secret key" --> "private key", "secret RSA exponent" --> "private RSA exponent" (to match "RSA private key"

parameter and terminology in [RFC8017])



E9. Sec. 4.3, "Input:" / "pi_string": "length k" --> "length n"



E10. Sec. 5.3: Reverse order of "pi_string", "alpha_string" in ECVRF_verify function call and "Input:" list (to match API in Sec. 2)



E11. Sec. 5.6.1, step 14: "bad_pk[0]...bad_pk[6]" --> "[bad_pk[0], ...,bad_pk[6]] (to use set notation rather than concatenation -- compare with step 3 in Sec.

5.4.3)



E12. Sec. 7.5, line 5: "Initialized" --> "Initialize"



E13. Sec. 7.7, next to last para: "RSA VRF" --> "RSA-FDH-VRF"



E14. Sec. 7.7, last para, "elliptic curve VRF" --> "ECVRF"



=====







From: CFRG <[e-mail]> On Behalf Of Nick Sullivan
Sent: Monday, October 25, 2021 3:07 PM
To: [e-mail]
Subject: [EXTERNAL] [CFRG] Last call for draft-irtf-cfrg-vrf-09



Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Dear CFRG participants,



The VRF draft has received significant reviews from the RG and the crypto panel and is ready for a second last call. This email commences a last call for this document that will end on the last day of IETF 112 Online (12 Nov 2021):



https://datatracker.ietf.org/doc/draft-irtf-cfrg-vrf/<https://secure-web.cisco.com/1TboK7-gRSZUizkFiD2kXEsavkV_3eVyp5oUUJUw0czoB-x0ujkOBU5BtJLxEr00gdiXE7Fs7_INt9y2wnAlLHX7pGX6t4aU3mhSFpCoyGUtvyKcTacYEv2UxuDTFIudt9w8t-zWZOucuiLZAFx8ezyLvBxjVXzuFWreMqRuRFYEmEGSAGEPgMpRdnrzFAssUINa01Mgrnk1pO-jrALwlNnzbMgqreHF48h5H6rIP6ihH3khmlz5R6OZ4OgsmgeNs/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-irtf-cfrg-vrf%2F>



If you've read the document by the end of this period and think that it is ready (or not ready) for publication as an RFC, please send a message in reply to this email. Detailed comments would be helpful. You can reach out directly to CFRG chairs ([e-mail]<mailto:[e-mail]>) if you have questions about the process.



Thank you,

Nick, Stanislav & Alexey