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

From: Sean Shen 沈烁 <[email-masked]>
Date: Wed, 16 Nov 2011 16:05:27 +0800

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: [email-masked] [mailto:[email-masked]] On Behalf Of David McGrew
Sent: Wednesday, November 16, 2011 3:35 AM
To: [email-masked]
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

---

From: David McGrew <[email-masked]>
Date: Wed, 16 Nov 2011 04:35:31 -0800

Thanks Sean.

On Nov 16, 2011, at 12:05 AM, Sean Shen 沈烁 wrote:

> 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.

In general I think that the more information, the better.  Mentioning  
reference implementations, or even just open-source portable software,  
seems like a good idea to me.  We won't have room to mention every  
implementation, of course, but I don't see why that should stop us  
from mentioning the important ones.

> I will be happy to contribute either as an editor or reviewer if  

great, thanks.

David

> 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
> 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.
>