Re: [Cfrg] proposed RG action: draft-cfrg-cipher-catalog

Sean Shen 沈烁 <shenshuo@cnnic.cn> Wed, 16 November 2011 08:05 UTC

Return-Path: <shenshuo@cnnic.cn>
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 8EDCD11E81EB for <cfrg@ietfa.amsl.com>; Wed, 16 Nov 2011 00:05:21 -0800 (PST)
X-Quarantine-ID: <qROzPASvjknQ>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID"
X-Spam-Flag: NO
X-Spam-Score: -1.496
X-Spam-Level:
X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MSGID_FROM_MTA_HEADER=0.803]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qROzPASvjknQ for <cfrg@ietfa.amsl.com>; Wed, 16 Nov 2011 00:05:21 -0800 (PST)
Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 9B78E11E81EA for <cfrg@irtf.org>; Wed, 16 Nov 2011 00:05:16 -0800 (PST)
Received: (eyou send program); Wed, 16 Nov 2011 16:05:12 +0800
Message-ID: <521430712.30401@cnnic.cn>
X-EYOUMAIL-SMTPAUTH: shenshuo@cnnic.cn
Received: from unknown (HELO pc309161504067) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 16 Nov 2011 16:05:12 +0800
From: Sean Shen 沈烁 <shenshuo@cnnic.cn>
To: 'David McGrew' <mcgrew@cisco.com>, cfrg@irtf.org
References: <521385734.28883@cnnic.cn>
In-Reply-To: <521385734.28883@cnnic.cn>
Date: Wed, 16 Nov 2011 16:05:27 +0800
Message-ID: <002f01cca436$824c27c0$86e47740$@cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acyjzb4b7Y3LexgpRi2zSOj+tE7b+QAZkG5g
Content-Language: zh-cn
Subject: Re: [Cfrg] proposed RG action: draft-cfrg-cipher-catalog
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Nov 2011 08:05:21 -0000

Hi, David,
I think it's a valuable work. Because I sometimes faced questions from many people who want to know overviews about cipher choices, security level and IPR issues, and it's not handy to give then a overview resource after explanations. 
Besides the contents you mentioned, I think overview and reference of available implementations or choices might also be useful. 
I will be happy to contribute either as an editor or reviewer if needed.
Best,

Sean 

-----Original Message-----
From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of David McGrew
Sent: Wednesday, November 16, 2011 3:35 AM
To: cfrg@irtf.org
Subject: [Cfrg] proposed RG action: draft-cfrg-cipher-catalog

Hi,

I would like to propose the creation of an research group draft that describes all of the ciphers defined or used in IETF RFCs.  This draft should contain the basic facts about each cipher, including intellectual property considerations, and also describe its security  
properties, and provide authoritative references.   The most important  
security considerations are key size and block size (though we have two stream ciphers that accept IVs and one that does not), and probably the easiest way to deal with this is to describe the security ramifications of the different parameter choices, which puts each cipher into a rough category.  There are about twenty such ciphers (see the attached html table) and it will be valuable for CFRG to put together this information and ensure appropriate review.

There has been discussion in some IETF working groups about the addition of new standards-track ciphers.  CFRG should be providing technical input, but it is not the right place for discussion of standards.  I think a draft focusing on technical properties is the right contribution.

Let me know what you think.  Are you willing to participate as an  
editor, contributor, or reviewer?   Do you see any problems with this  
approach?   Anything missing from the outline above?   Comments  
especially welcome on the subject of security categorization.

thanks,

David