Subject: Re: RSA vs. DSA MUST

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 29 Nov 2000 16:18:47 -0700

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" <[email-masked]> 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

---

From: "Enzo Michelangeli" <[email-masked]>
Date: Thu, 30 Nov 2000 11:59:47 +0800

----- Original Message -----
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Thursday, November 30, 2000 7:18 AM
Subject: Re: RSA vs. DSA MUST

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

I think that Product Management needs to understand that in the Internet age
interoperability is, for a vendor, matter of life and death; I think your
company grasps this point well, as it bit the bullet several years ago by
embracing TCP/IP.

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

Gee Bob, you stole my line: I was planning to title one of my postings "The
X.400-ization of secure e-mail". Does everyboy remember X.400 (1984) and
X.400 (1988)? Both S/MIME and OpenPGP, at this moment, exist in two major
versions that do not necessarily interoperate with each other, and for the
same damn reason (old intellectual property issues on cryptographic
algorithms, now in large part disappeared).

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

Here is my modest proposal for SMIME v.3 sole MUST requirements:

- Full interoperability with SMIME v.2, therefore #include-ing all the MUST
of RFC2311;
- Minimum key length raised to 1024-bit for PK and 112-bit for symmetric
algorithms;
- At least one other key exchange algorithm and one signature algorithm
unrelated to the problem of modular factorization, to protect against
possible unpleasant effects of progress in numbers theory. I'd say that DSA
and DH are the best candidates, if we want to exorcise the IP curse that
could strike ECC-based techniques;
- 3DES-EDE and Rijndael added to RC2.

Cheers --

Enzo

---

From: "Bonatti, Chris" <[email-masked]>
Date: Thu, 30 Nov 2000 10:21:32 -0500

> - 3DES-EDE and Rijndael added to RC2.

Enzo,

This isn't actually too modest in my view.  In terms of numbers of things
supported it's not too far from where we are now (just a few attributes).  I
would support this with one addition.  I think you *need* to support the
'SMIMECapabilities' on reception.  This just seems like a necessity in any
environment that supports multiple algorithms.  Otherwise, you have all you need
for basic interoperability.

Chris

---

From: "Bonatti, Chris" <[email-masked]>
Date: Thu, 30 Nov 2000 10:20:51 -0500

Bob,

Did I mention that sticking my arm into hornets nests is one of my favorite hobbies. ;-)  This nest look good and ripe...

> 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 requireme…

I think that most of the "feature creep" to which you refer is in the realm of options.  There is still a fairly small core of S/MIME features that are MUSTs, and nearly all of them have some core interoperability reason.

<snip>

> 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 fac…

Okay, but you're arguing against something that I'm not saying.  I'm not saying that anything should be MUST (in fact, I think the reverse should be the case).

I am also NOT saying that we should implement these algorithms because the government says so (like Ada, etc.).  What I'm saying is that two years ago WE said is was good enough, cheap enough, etc.  Now suddenly it isn't.  What gives.  I'm trying to point out some intellectual disingenuousness, not arguing for an end state.

> 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 h…

This seems a little overstated.  As a developer, surely you have the latitude to design your GUIs the way you want.  That doesn't stop you from supporting whatever algorithms you want, or auto-selecting based on the 'SMIMECapabilities'.

> 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 'SMIMECapabilities' attribute is a MUST on reception, and a SHOULD on origination.

On your second point, you have zeroed in on the point of my third bullet admirably.  If the MUST doesn't mean much, why are we debating it like it's a meaningful decision?

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

However, by this logic nothing ever improves.  I'm not knowledgable enough to say whether DSA/D-H is an *improvement* over RSA, or just another choice.  Nevertheless, I think this evaluation should be a factor.  Somebody else asked the question too.  (?)  Is DSA/D-H better?  If not, then its okay to stick with what's out there.  If is it, then we've got to decide if it's better enough to be worth upgrading the infrastructure.  I have not even heard this point raised yet.  Why not?

All the best,
Chris sends...