Re: [CFRG] [irsg] IRSG review request: draft-irtf-cfrg-vrf-13
Leonid Reyzin <reyzin@cs.bu.edu> Thu, 25 August 2022 22:16 UTC
Return-Path: <leonid.reyzin@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBF2C14CE3E; Thu, 25 Aug 2022 15:16:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.404
X-Spam-Level:
X-Spam-Status: No, score=-1.404 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wH0EECmMMl0E; Thu, 25 Aug 2022 15:16:09 -0700 (PDT)
Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C41CC14CE3C; Thu, 25 Aug 2022 15:16:09 -0700 (PDT)
Received: by mail-ej1-f45.google.com with SMTP id d21so22812646eje.3; Thu, 25 Aug 2022 15:16:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=HlZmHWSuWeygPkEzo0vZcYSExUcgINg6B94aFYVYvqY=; b=OXyzBi1kXIyjkcCP5qfZbM1vod2IAhSItgshds630p/zrh00F50u45jXrIMvFUvOGp GMzRUkGI+aiZYBVUAzayw92Mm3D0VhqvXQOKshPbtb/PvTs1fRrNWIJfHaWuuqyWkPf0 Ww6nenKbvIRk1+ySwjRkbZRVJ1qSyAa3Eg4mLgiklR+T4I6XBPzoAfP5Nyf23rajMCcq zndZScDX2NAUvN7txupghz9qqLFlvsor1EwGXDJXGScLIaCW99UR2SFdAV2kEIWZfi8t g4B88q26vWqQQu5HsovmLOIQ/k0ywp55M3DvOgUVBvxZ9o5Es0E6UTf6N9ZcrXqahWNq 2bxg==
X-Gm-Message-State: ACgBeo3+VAzkbRicst74YwDhVNNkqk7nOPlt705RVexsNtb0yXbs6WeW Tk3ixxOkz4j5OMH4ewo4KjGXQBLKF41Y1Rie24A=
X-Google-Smtp-Source: AA6agR7ukaL+SoD7lAs+EH4okvoP0nOnReZii67uKSGCTqhRa5BHcQw4o9a/Uh8g1qDORMIEFm4qWf8rbasEMuYMUHA=
X-Received: by 2002:a17:906:eecb:b0:73c:5bcb:8eb3 with SMTP id wu11-20020a170906eecb00b0073c5bcb8eb3mr3694189ejb.284.1661465767242; Thu, 25 Aug 2022 15:16:07 -0700 (PDT)
MIME-Version: 1.0
References: <66620D79-509D-4036-95CB-8D8CEE1227D2@csperkins.org> <9625f922-fba2-c2fa-07f1-a297d2ffd5e2@cdt.org> <CAHZ6D0tXPE45az=J9AUT3NDgx=9TEDAdO81hbU2xwTFm4o2gxw@mail.gmail.com> <38A0BAE0-657F-4EF5-A1F8-0F20995116EC@csperkins.org> <799f629f-7575-5e92-9672-d167c73e257a@cdt.org> <8A429DBA-3DAC-4F3B-8834-C91DD3AED9A8@csperkins.org>
In-Reply-To: <8A429DBA-3DAC-4F3B-8834-C91DD3AED9A8@csperkins.org>
From: Leonid Reyzin <reyzin@cs.bu.edu>
Date: Thu, 25 Aug 2022 18:15:40 -0400
Message-ID: <CAHZ6D0ubZpWyw3KC7p1vTtCCnX6=_fkn-JEgwpXN6rT=u6ht+A@mail.gmail.com>
To: Colin Perkins <csp@csperkins.org>
Cc: Mallory Knodel <mknodel@cdt.org>, Internet Research Steering Group <irsg@irtf.org>, CFRG <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="000000000000dcef5b05e718242a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/-eOQlvXD8HdfAfzVOCh5yYWuSr4>
Subject: Re: [CFRG] [irsg] IRSG review request: draft-irtf-cfrg-vrf-13
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Aug 2022 22:16:11 -0000
No outstanding issues. Thanks! On Thu, Aug 25, 2022 at 5:25 PM Colin Perkins <csp@csperkins.org> 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 <mknodel@cdt.org> 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 > >
- Re: [CFRG] [irsg] IRSG review request: draft-irtf… Mallory Knodel
- Re: [CFRG] [irsg] IRSG review request: draft-irtf… Leonid Reyzin
- Re: [CFRG] [irsg] IRSG review request: draft-irtf… Colin Perkins
- Re: [CFRG] [irsg] IRSG review request: draft-irtf… Mallory Knodel
- Re: [CFRG] [irsg] IRSG review request: draft-irtf… Colin Perkins
- Re: [CFRG] [irsg] IRSG review request: draft-irtf… Leonid Reyzin
- Re: [CFRG] [irsg] IRSG review request: draft-irtf… Colin Perkins