Re: [Cfrg] CFRG Review Panel - Draft Charter

[[e-mail]]

Hi Yoav,
I generally agree with what you have outlined. The problem is that how these issues could be addressed within proposed 2-4 weeks period. As for me CFRG should be focused on crypto: implementation issues or suitability for a specific protocol  should be left for other working groups. As for crypto it is obvious that 2-4 weeks period is not enogh for profound cryptoanalysis. I think that the best reviewers could do - is to present a state-of-the-art in cryptoanalysis of the proposed mechanism, and possibly show what issues are missed. So, to my mind, such a review should contain a list of publicly availiable results of cryptanalysis, or results which could have a relation to the cryptanalysis of the proposed mechanism.
Grigory
--
Отправлено из Mail.Ru для Android вторник, 10 мая 2016г., 23:14 +03:00 от Yoav Nir < [e-mail]> :

>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
>
>_______________________________________________
>Cfrg mailing list
>[e-mail]
>https://www.irtf.org/mailman/listinfo/cfrg