ietf-smime
[Top] [All Lists]

Re: RSA vs. DSA MUST

2000-11-29 16:18:15
Chris, I believe these points are important, and perhaps more important than 
the particular issues at hand.  So please allow me to wax philosophical.

As a consumer, all things being equal, I like products that support lots of 
interoperability modes too.  Beer, champagne, hot dogs, filet mignon, ice 
cream, apple pie, floor wax and desert topping -- they're all great, at least 
if you can afford them.

But as a vendor, I am increasingly concerned about the amount of feature creep 
that we are seeing every day in both the PKIX and SMIME groups, apparently  
almost unconstrained by business requirements.  We need interoperability, and 
that should not mean lowest common denominator, but it also shouldn't mean 
being all things to all men.

Although the development cost of adding a particular feature tends to go up 
linearly, the testing and interoperability costs tend to go up with the SQUARE 
of the features, all of which generally have to be tested in all possible 
combinations.  That is both expensive and time consuming, and leads to products 
that are either buggy or late, or typically both.  And that clearly doesn't 
benefit the consumer at all.

As a result, Product Management is increasingly inclined to "Just Say NO" to 
these kinds of features, which ends up making IETF standards increasingly 
irrelevant and making interoperability that much harder, rather than easier.

The real challenge in creating standards is therefore not to attempt to see how 
many you can create with all of their rococo variations, but rather how few you 
can get by with and still get the job done.  To the extent that the IETF WGs 
become self-justifying, self-perpetuating, and eternal, the less useful they 
become, IMHO.  We are becoming more and more like ISO every day, and maybe 
worse.

Now allow me to (gently, I hope) take issue with some of your other statements:

"Bonatti, Chris" <BonattiC(_at_)ieca(_dot_)com> 11/29/00 02:58PM >>>
   Reading through this thread, I am astonished at a couple of apparent 
truisms that are emerging from the various earnest statements made.  These 
are 
(employing a little editorial license):

  * The implementation cost of DSA/D-H/3DES was acceptable when RSA was 
patented, but now that some of us have actually built/tested this the cost 
has gone up into the "too high" range.

I would disagree.  The cost of the RSA license was minimal relative to other 
development costs, and the RSA algorithm was effectively all there was in terms 
of deployed PKI infrastructure.  The fact that DSA and D-H were labeled MUST 
was chalked up to IETF politics, and completely ignored by the vendor community 
as not being worth the implementation cost in terms of revenue return. Granted, 
it didn't meet some of the expressed desires of the US Government, but the USG 
has always had a much bigger appetite than budget.  (Remember Jovial?  Ada?  C2 
by '92?)  Money talks, and everything else walks.  They imposed requirements, 
but those requirements didn't stick when it came to real procurements.

  * Specifying a single MUST algorithm suite was sufficient to make S/MIME 
algorithm independent, but actually requiring two algorithms suites will cost 
too 
much.  If we've really achieved algorithm independence in the sense that Dave 
Kemp suggests, this should be a debate about a relatively small math module.

No, again I disagree.  The math module isn't the problem.  As a BSAFE licensee, 
we already have all of the math modules we would need.  The real issue is all 
of the multitudinous GUI screens that have to be developed to allow the user to 
choose this, that or the other algorithm within S/MIME, and then the same set 
of choices in any PKI products, and then testing all of these options in every 
conceivable combination, not just within a given product but in combination 
with all of the other leading e-mail packages, plus the various PKI services 
and toolkits as well.  those costs dwarf the cost of the math module by a 
couple of orders of magnitude.

  * We have an 'SMIMECapabilities' attribute for which support is MUST, but 
some implementations ignore it so we have to use the lowest common 
denominator to force interoperability.  What make anybody think a MUST on an 
algorithm choice would be taken any more seriously?

Two issues.  As I recall, the SMIMECapabilities is a MAY, not a MUST, although 
I'll stand corrected if I'm wrong.  And as I say, and Peter Gutmann said more 
succinctly, MUST matters if and only if the vendor was inclined to implement 
that option anyway.  It might be sufficient to push someone over the fence who 
was already 49% there, but not much more.  Standards compliance doesn't pay the 
rent -- customers do.

   I don't think I actually have an opinion on this issue myself.  I'm of the 
mind set to mandate nothing and let Darwin decide.  However, I find the 
seeming 
illogic of these collective opinions very troubling.  It leads me to think 
that we're not getting to the REAL reasoning behind this move.

   I think Blake was closest to this in stating that there has been no 
customer demand for DSA.  Is this the REAL reason to dump DSA?  Are customers 
demanding RSA be used?  Do customers express demand for any algorithms, or do 
they just want it to be "secure"?  Are we just drifting to the path of least 
resistance?

Customers don't demand or specify algorithms.  They just want it to be secure, 
and trust that the vendor will figure out what that means.  What they do insist 
on, however, is that the product work well with the existing infrastructure in 
order to reduce their total overall cost of ownership.  The more sophisticated 
customers realize that adding more and more features that they never use 
significantly increases that TCO, so overburdening a product with unnecessary 
features causes a significant backlash.  Increased cost of development with 
decreased sales.  What a concept!

   Personally, I favor products that support LOTS of interoperability 
modes... not just lowest common denominators.  Call me crazy, but...

Chris B.

This is really a case of Little Red Riding Hood's porridge.  We want it to be 
not too hot (needlessly feature rich), and not too cold (missing important 
capabilities or security, forcing everyone to devolve to the lowest common 
denominator), but rather just right.  And that requires making intelligent 
CHOICES.

I like mustard, and I like chocolate.  But that doesn't mean that I want 
chocolate on my hot dog, nor mustard on my ice cream, just because I have them 
both in my refrigerator. :-)

Regards,

Bob


<Prev in Thread] Current Thread [Next in Thread>