RE: Clarifying controversial criteria

Blake Ramsdell (BlakeR@deming.com)
Thu, 14 Mar 1996 00:48:33 -0800 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.  Contact your
mail administrator for information about upgrading your reader to a version
that supports MIME.

------ =_NextPart_000_01BB113F.F96AABB0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

On Wednesday, March 13, 1996 5:21 PM, Raph Levien[SMTP:raph@cs.berkeley.edu]
wrote:
>> 
> I do not wish to engage in a flamewar about crypto export and
> keysizes. I do not believe it is possible to establish in a forum such
> as this one which of is "right." I do believe that it is possible to
> categorize the protocols on the basis of their stance towards algorithm
> selection, and that such a categorization is useful to those who wish to
> evaluate email protocols. That, in my understanding, is the entire point
> of Jim's original matrix.

I'm sorry if I twisted this into a "boy is ITAR stupid" discussion -- you're
right, let's get back on track.

For the sake of discussion, I will say that "those who wish to evaluate
email protocols" are the end users since I am a vendor.

The stance of S/MIME is "Use RC2 40-bit if you are communicating with
someone that has to use it, otherwise kick some ass and use a longer key"
(paraphrased, but accurate).  How could this be worded in such a way that
someone evaluating the protocol would understand that RC2 is potentially far
more secure than IDEA when used with longer keylengths, and thus should meet
their needs of a secure email package?  It seems to me that this wording is
strong enough, but I'm open to suggestions as to how to fix it.

The algorithm choices in our product are:  RC2 128-bit (the default), DES
EDE3-CBC (for compatibility with public-domain applications that don't have
an RC2 license), and RC2 40-bit (for export reasons).  How does this not
meet the customer's needs?  It provides security, interoperability, and
exportability all in one.

I will propose, however, that the ambiguous wording "support for RC2 at
higher key sizes" be replaced with "support for RC2 at key sizes greater
than 90 bits" in the S/MIME specification in order to satisfy this.

>    It is true that the "Secure Interoperablity" criterion penalizes
> protocols for which implementations can be legally exported from the US.
> That's because of the crypto export regulations, not the way I've
> formulated the criterion. I don't think I understand what you mean by
> "unfair".

I characterize this as "unfair" because even though my application
implements 40-bit RC2, it also implements n-bit RC2, and n can be much
higher than the fixed 128-bit length of IDEA, thus theoretically making it
"more" secure, even though arguing past 128 bits right now is splitting
hairs.

>>   I guess I just don't understand the reasons why you think the
>>criterion should be removed, other than the fact that it is unfavorable
>>to a product you are developing.

...And also unfavorable for any specification that allows for the
possibility of using an algorithm that is exportable.  The international
market is important to vendors, and there will always be a vendor that
chooses to implement an exportable version, which will cause that
specification to fail your criterion.

Because of what you have said about customers basing their specification
decisions (and ultimately their purchasing decisions) on this criterion, I
feel a need to beat this issue to death, since I and other vendors are
currently backing S/MIME as a candidate for the final round.  If the
customer won't buy it, then why should we make it?  And I don't believe
S/MIME fails the test of meeting the customer's needs, especially on the
basis of secure interoperability.

Blake

------ =_NextPart_000_01BB113F.F96AABB0--