Re: [Cfrg] CFRG Review Panel - Draft Charter

Yoav Nir <> Tue, 10 May 2016 20:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 35CA712D8D4 for <>; Tue, 10 May 2016 13:14:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TxnEM7Z5zVwv for <>; Tue, 10 May 2016 13:14:39 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A032F12D8CF for <>; Tue, 10 May 2016 13:14:38 -0700 (PDT)
Received: by with SMTP id e201so192872107wme.0 for <>; Tue, 10 May 2016 13:14:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=hXeSIRJTGp2ZZG3WOTsCyI72gQHEuChovnOu6rWkncs=; b=PqxcQz4leTnAIYm9lEU+wjULQlFPam0TjRbgiE6Bz8A+eFmj/CV2HTCsauZZC1ZldR hWSqwp2aNVq5e/ZAXwoM6mJZoOKzpKoN9A+zPyE3MRJAmttx53vM1e1pbDMkWoYlI1RK Gg3p7k6fyVtWuZAd2c3CwCdjg6f8u7Ejovapx/7+7xps1jMzJOuupjb4x2Oo+bHNuITl 3QQsdi0vR3F7VnL4jerjt6iol1So5m/Ec4QxaNE8u0kUOCcAibjA8dDrkdUPuj6ToeFZ FkJtxpo1VuxOdH8BOkWJKuqWmx+krpRscmJR4K7C2L0kmhRHqELgDNqf0u1lZzdy2R8w I1Xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=hXeSIRJTGp2ZZG3WOTsCyI72gQHEuChovnOu6rWkncs=; b=lXjJ7fHBa0oj9R9468h06Jpjjy2P3EdOxf+TudJCRxfWpy34+ig74sSS0rOQNgEHds VlYWmGwduf1LmQPtz7SpNgGhpFMS9L7ZKOxOmL+9rdVYzqhqMTSTjiqPnpeAITQFFagm WfxVhdv34M0JlLpZ/KZ5YzdPIqEicmnV/PgyebhwXjW8UHRhC3Aj4E5P+dDbJTL+iE7P bmzqKPQmKg27QAxQytllE3rvokZ1SaCGNPQVr5NyPVr0LtZnmSkfl4l71+ie/y6/dBNN xr/ddD8aH9GRFsmDepJrePLQmqXKwc6I4wfHuN9cxxJ/0CAuJIvMUP6jyosCYqHQbTfE Q8WQ==
X-Gm-Message-State: AOPr4FUP2z0MBT79utM9VNJwhvSErrGvev7m8tgE4ND1zro6bum6fCkfX/hWqB5is9vDJA==
X-Received: by with SMTP id s12mr41350097wjw.24.1462911277151; Tue, 10 May 2016 13:14:37 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id t201sm32037279wme.11.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 10 May 2016 13:14:36 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_B8135B5B-B115-47C6-A79A-AD72DA59173C"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Tue, 10 May 2016 23:14:33 +0300
Message-Id: <>
References: <>
To: Alexey Melnikov <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Resent-From: <>
Cc: "" <>
Subject: Re: [Cfrg] CFRG Review Panel - Draft Charter
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 May 2016 20:14:42 -0000


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.


> On 10 May 2016, at 3:56 PM, Alexey Melnikov <> 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