Re: [Cfrg] CFRG Review Panel - Draft Charter

"Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> Wed, 11 May 2016 11:41 UTC

Return-Path: <Kenny.Paterson@rhul.ac.uk>
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 02A8B12DA6A for <cfrg@ietfa.amsl.com>; Wed, 11 May 2016 04:41:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDiwAMuKsnD2 for <cfrg@ietfa.amsl.com>; Wed, 11 May 2016 04:41:12 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0066.outbound.protection.outlook.com [104.47.2.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 331B212DA5A for <cfrg@irtf.org>; Wed, 11 May 2016 04:39:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tEu4emEY4+yKnW2PDjDY5N4mXeM9Uw67O6ffn898dzM=; b=lg6LQQHUpId5kfmsOz2CtKmoN8D98uyFSdFHiEw2rVWwSeGc+JQf+H+9+2PbPVMbhs5xB5a5lhc7DLnJa/4esYQClXaD/qpC9OejCYUdBnJ0ObCQ96BjikllQIMmttrUG5YDuSHsfBaTw5hCOh0sodqX7mGo9P4taVCHqQsTebk=
Received: from VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) by VI1PR03MB1824.eurprd03.prod.outlook.com (10.166.42.150) with Microsoft SMTP Server (TLS) id 15.1.492.11; Wed, 11 May 2016 11:39:51 +0000
Received: from VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) by VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) with mapi id 15.01.0492.016; Wed, 11 May 2016 11:39:50 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: Yoav Nir <ynir.ietf@gmail.com>, Alexey Melnikov <alexey.melnikov@isode.com>
Thread-Topic: [Cfrg] CFRG Review Panel - Draft Charter
Thread-Index: AQHRqrpB7uJdOYB4nkmSuzAd3KJ4JJ+ym62AgAETfIA=
Date: Wed, 11 May 2016 11:39:50 +0000
Message-ID: <D358D89D.6C1A1%kenny.paterson@rhul.ac.uk>
References: <B8C1696D-A9B3-4CC5-A9E3-2F4C155ACCCA@isode.com> <9D2D5FC6-71B1-44D7-94CB-5804C534242F@gmail.com>
In-Reply-To: <9D2D5FC6-71B1-44D7-94CB-5804C534242F@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.3.160329
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=rhul.ac.uk;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [213.47.226.15]
x-ms-office365-filtering-correlation-id: 61519abe-4027-4e44-6f1f-08d37990f646
x-microsoft-exchange-diagnostics: 1; VI1PR03MB1824; 5:t3tIE46UX9eB5berZ/9tfO5QnO7Vz4IKxXYxbrzQbj7y6mxI0GTKdLQS6b2wPO44VhYq9bMcxUm5CgWd4uYS18CaAbnkBcQyptyMw97Qk0cmdG9XcYxXw/ipF/ez70MFYqVPZHMRXfW0fi2Euz6Sgg==; 24:q6ulLesK3aa2KcJoqHVQGrWrAQTOy42IY5MMj27syY/RghGtby8NjhIhlbcVUWddK6+fdvpkJSFz7XiLOXQ5IrzJooqexPBW5cHfQLzxVtk=; 7:wDNC+ANPJlYyzJf70oJEijilpKcBO77X3+HUqywQEFJSmpmbC+EE13TJSg7WZ1X8znvRHu8ii3jFWk2/mI4gYAd/vqaRndgyVBf1kqz/duMXz+RZfup9ftJn5QkK09Bqf2XXfDyeJPLTDaFCs4FStSUvLrqPjvUt8RRWemHpXc0mAcsAYH7AcANxnL/w6YZh
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1824;
x-microsoft-antispam-prvs: <VI1PR03MB18249A07D42E9257AA8B6D3CBC720@VI1PR03MB1824.eurprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR03MB1824; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1824;
x-forefront-prvs: 0939529DE2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(51914003)(24454002)(36756003)(189998001)(4001350100001)(5001770100001)(81166006)(74482002)(3280700002)(3660700001)(10400500002)(8936002)(5004730100002)(122556002)(1220700001)(76176999)(4326007)(2906002)(50986999)(5008740100001)(54356999)(5002640100001)(19580395003)(3846002)(87936001)(92566002)(561944003)(102836003)(6116002)(2950100001)(86362001)(586003)(15975445007)(106116001)(66066001)(77096005)(2900100001)(83506001)(19580405001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1824; H:VI1PR03MB1822.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <F339EF359014A3449255D3A8A26FC50B@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2016 11:39:50.1246 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1824
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/nVYepcDuVxDVuPye4iEpi3ZvpXI>
Resent-From: <alias-bounces@ietf.org>
Resent-To: @ietf.org
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] CFRG Review Panel - Draft Charter
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
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: Wed, 11 May 2016 11:41:15 -0000

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" <cfrg-bounces@irtf.org
on behalf of ynir.ietf@gmail.com> 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 <alexey.melnikov@isode.com>
>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
>Cfrg@irtf.org
>https://www.irtf.org/mailman/listinfo/cfrg
>
>
>
>
>
>