Re: [Cfrg] CFRG Review Panel - Draft Charter

["Paterson, Kenny" <[e-mail]>]

Hi Yoav,

Thanks for these suggestions. We're most definitely open to clarifying the
scope of reviews and the expectations placed on reviewers.

Best

Kenny 

On 10/05/2016 21:14, "Cfrg on behalf of Yoav Nir" <[e-mail]
on behalf of [e-mail]> wrote:

>
>
>
>Hi.
>
>
>I like the idea, but I would like to have more clarity on what we expect
>such a review to contain.  We currently have this:
>
>
>
>Reviews will identify issues - both security issues and deployment issues
>- but not necessarily
> low-level nits and typos. Reviews will also identify relevant research,
>or the need for further research.
>
>
>
>Some things I think the output from such a review should contain:
>
>* Differentiation - how is this crypto different from common crypto. If
>there is a proposal for using some new (national or not) block cipher,
>the review should say in what ways this is better than AES. I mean,
>nobody’s going to propose in 2016 something
> that isn’t better than AES at least in some respects. If it’s a
>signature algorithm, I’d like to know what useful property it has that
>RSA, ECDSA, or EdDSA don’t. Speed is a differentiator; block size is
>another; some elegant security proof that cannot be
> done to other algorithms is yet another. Or maybe some new and useful
>property.
>* Use cases - not every algorithm is better for every use case. The group
>is considering AES-GCM-SIV. If that was under review, the review would
>note the differentiator - that nonce reuse leads to far milder
>consequences than in current algorithms.
> But nonce reuse doesn’t happen in many of our favorite protocols: SSH,
>TLS, IPsec, S/Mime, so AES-GCM-SIV is not a good algorithm for any of
>those, or at least no better than regular AES-GCM. I’d like a review to
>tell what kind of protocols or use cases might
> benefit from an algorithm with this property, such as multicast IPsec
>with multiple senders or group unicast IPsec such as Cisco’s GET-VPN.
>* Some conclusion from reviewing the research. I’m looking for a
>subjective assessment of how confident we are that this algorithm is
>good; Whether it is safe to begin using it in protocols that protect
>high-value data.
>
>
>
>
>Yoav
>
>
>On 10 May 2016, at 3:56 PM, Alexey Melnikov <[e-mail]>
>wrote:
>
>Dear CFRG participants,
>Kenny and I would like to solicit comments on the Crypto Review Panel
>that we announced in Buenos Aires.
>
>
>We would like to solicit review of objectives and process outlined below.
>Please express your opinions and/or suggest your edits by the end of May
>22nd. Both replies to the mailing list and directly to chairs are
>welcomed.
>
>
>Best Regards,
>Kenny and Alexey
>
>
>CFRG Review Panel
>
>
>
>
>
>
>Objectives:
>
>
>CFRG is a volunteer-led activity that currently relies on the goodwill of
>its participants
> to provide review of documents. This can result in documents not
>receiving enough scrutiny, or examination only being forthcoming
> over an unacceptably long period of time. Also, there is lack of
>consistency between reviews of different documents.
>
>
>The CFRG Review Panel will ensure that CFRG chairs have at their disposal
>sufficient resources
> and lightweight processes to provide critical, objective, timely and
>consistent review of cryptographic algorithms
> in IRTF and IETF documents.
>
>
>The recommendations coming out of panel reviews will not be binding on
>CFRG, but are intended
> to provide high-quality input to augment the usual development process
>for CFRG drafts.
>
>
>Reviews will identify issues - both security issues and deployment issues
>- but not necessarily
> low-level nits and typos. Reviews will also identify relevant research,
>or the need for further research.
>
>
>
>
>
>
>Processes:
>
>
>When CFRG chairs decide that a document would benefit from a panel
>review, they will select
> one or more reviewers and request a review within a given time period
>(typically 2 to 4 weeks). Reviews will be made public via
> the CFRG mailing list; private discussion between reviewers, authors and
>CFRG chairs may also take place.
>
>
>A document's authors may identify conflicts and conflicts of interest
>with particular panel
> members. Such conflicts should be notified to the CFRG chairs by the
>authors (or panel members) when the chairs initiate the
> review process.
>
>
>Not every CFRG draft needs to be reviewed by the panel; documents that
>are not CFRG drafts
> may also be reviewed by the panel.
>
>
>The CFRG chairs will make appointments to the Review Panel.  The panel
>will be composed
> of 6-8 members; it may be increased in size by the CFRG chairs should
>the number of documents to review necessitate the increase.
>
>
>Reviewers will be appointed to the panel for a period of 2 years,
>renewable. The CFRG chairs
> will endeavour to ensure that the Review Panel has a balanced
>composition covering the main technical areas of relevance
> to CFRG. Individuals may self-nominate or nominate others for panel
>membership.
>
>
>Being a panel member represents a commitment to review documents in a
>timely and thorough
> fashion; reviewers' panel membership will be rescinded at the discretion
>of the CFRG chairs.
>
>
>
>
>
>
>_______________________________________________
>Cfrg mailing list
>[e-mail]
>https://www.irtf.org/mailman/listinfo/cfrg
>
>
>
>
>
>