Re: Clarifying controversial criteria
Raph Levien (raph@cs.berkeley.edu)
Thu, 14 Mar 1996 12:23:40 -0800
Blake Ramsdell wrote:
>
> 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.
That's not what I have problems with (although I am suddenly quite
curious how S/MIME conveys the information to the sender which
algorithms the recipient is capable of - if anybody has the answer, I'd
be very grateful). The S/MIME implementation guidelines even go so far
as to specify 40-bit RC2 as the "recommended default" for outgoing
messages. It also strongly recommends using "[s]tronger content
encryption ... where there is some mechanism to indicate that the
intended recipient(s) can support it." What kind of mechanism is
intended here? Is there any indication it will be widely deployed?
I agree that the stance of S/MIME is (even more paraphrased), "use
40-bit where you have to, better when you don't." Whereas the stance of
PGP is "if you have to use 40-bits, it isn't Pretty Good Privacy." That
is the distinction.
> 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.
Very good point. All of the viable choices (only PEM needs to be
excluded) offer security. As you assert, S/MIME offers security,
interoperability, and exportability. What I'm saying is that it doesn't
offer Secure Interoperability, according to my criterion. The difference
is whether interoperation guarantees security, or whether it can force
the protocol into insecure operation.
> 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.
I have no objection to this, but presumably implementors will use the
maximum keysize available anyway.
> > 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.
Your answer misses the entire point of my criterion. The product you
ship overseas will not implement any algorithm except for 40-bit RC2.
Please explain to me how I can securely interoperate with such a
product.
> >> 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.
I'm trying to be as fair as I can. That's the main reason why I included
the "exportable" 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.
I also have a strong desire to resolve this issue. However, I feel that
the decisions made by S/MIME will result in the deployment of an email
client infrastructure of which large parts are insecure. For
organizations desiring security, and with unsophisticated users who
believe that the "S" in S/MIME stands for "secure", and who do not
understand the subtleties of keysize choice, the protocol will let them
down. I do not see how pointing this out could possibly be considered
"unfair."
The designers of S/MIME made some choices, one of which was that
Exportability was more important than Secure Interoperability. It may
well be that this was the right choice. However, I feel an obligation to
explain to people what those choices were and to help them understand
the implications of those choices. The criteria I proposed represent my
best effort to do so, as fairly as possible. I'm very open to being
shown where my criteria fail in these goals, but so far your arguments
have not convinced me.
Raph