Re: RSA vs. DSA MUST

["Bob Jueneman" <bjueneman@xxxxxxxxxx>]

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@xxxxxxxx> 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