Re: Is S/MIME Secure?
Brad Knowles (brad@his.com)
Sat, 16 Mar 1996 01:25:02 -0500
At 5:34 PM 3/15/96, Bob Dickinson wrote:
> Essentially, stand-alone utilities like the current implementation of
> PGP will have an easy time in meeting the "Secure Interoperability"
> criterion since the user will only use them if they are sending a secure
> message. As we start to see real e-mail products that deploy security,
> including PGP, then those products will all lose on this criteria as they
> will certainly need to have the ability to send non-secure messages to
> remain interoperable with other users who don't have any (or compatible)
> security.
For folks who have nothing (to use the previous Word example),
the only level of interoperability that you can ever have is plain
text files (i.e., no encryption, since the other guy has no ability
to decrypt it). You could have digital signatures, and I would argue
that implementors should look into what it would take to make it very
difficult or impossible to turn off generation of digital signature
for all messages.
I don't think anyone is going to argue with this point.
What I think we want to do is virtually eliminate the possibility
that, for those who have some form of security, that they will be
incompatible with ours. We don't do that by supporting everything
everyone is capable of (that's a recipe for lunacy), but instead by
having products based on the standards we help promulgate so
ubiquitous that the probability of anyone having an incompatible
produt is vanishingly small.
> My second area of concern lies with the fundamental underpinnings of the
> arguments made by those supporting the current interpretation of the
> criterion. That is that the capability of operating in a non-secure way
> implies the lack of security.
You have a toggle switch -- the person on the other end can
handle secure mail or they can't. For those who can, you want to
guarantee that it is really secure (not just pretend security like
RC2 at 40 bits), and that it is also virtually guaranteed to
interoperate, by simple virtue of it being secure. I think this is
what Raph means by Secure Interoperability -- it's certainly what I
think of when he says that, and I agree that this is what I want.
> I am somewhat reluctant to suggest this, but I would like to see the
> response of the vocal opposition. What if there was a new classification of
> S/MIME called S/MIME Level 2, that was exactly the same as the current
> specification except that it didn't support any weak crypto (like the
> current exportable stuff). Now, would that protocol get the plus sign for
> "secure interoperability"? What if my application supported both S/MIME and
> S/MIME Level 2, would my application get the plus sign? It seems like the
> protocol would get the plus sign, but that my app would lose given that it
> is "capable" of doing week crypto. Does this really seem like a useful
> criterion for the purpose of evaluating a product? If not, then what is
> it's utility as in evaluating a protocol independent of a product?
If your product implemented only S/MIME Level 2 or nothing at
all, then yes, I think it would rate a plus sign. If it supported
both Level 1 and Level 2, it could operate in a mode whereby a user
could send messages that they believe to be secure, but which really
aren't (by dint of keylength, or more accurately, the lack thereof).
And a product that did both would continue to fail to rate a plus
sign, because it is capable of operating in a non-secure mode when
the user believes that it is actually secure.
Now, as an implementation detail, you could make Level 2
read-compatible with Level 1, and I think that this should still
qualify.
But, now you've lost your exportability.
As I have said before, the average user can't even program their
own VCR. For some, the concept of pushing a single button can be
difficult. It is our job to make this entire process (standards and
the products based on them) as idio-resistant as possible, and
therefore make it as difficult as possible for the user to screw up
and somehow manage to be insecure when this was *not* their
intention.
I liken this change in focus to be similar to the legal concept
of "Innocent until proven guilty" vs. "Guilty until proven innocent".
Well, the users are assumed to be guilty of stupidity and idotry
until proven otherwise, and we have to make the results of our
efforts so easy to use that they simply can't manage to easily screw
them up (nothing is ever totally idiot-proof).
Exportable Secure Interoperability right now is a physical
impossibility, and you have to decide which of these three terms
you're willing to give up. I'm not willing to give up any of them,
at least not yet.
IMO, I think we're in the "deceased equine flagellation" stage.
I think we all agree that what we want is Exportable Secure
Interoperability, and that we should document this fact and work on
it to the best of our ability as a parallel effort (including being
involved in legal action against the United States Federal
Government), and get on with our other work.
When we talk about current standards and products, I think the
distinctions that have been made so far are valid and continue to be
useful. But when we talk about the standard we're trying to create,
I think we should set the goal for ourselves of producing a standard
that guarantees Exportable Secure Interoperability, and simply accept
nothing less. And not worry in the meantime about how we're going to
do that, because that is controlled by external political factors,
and we still have technical problems to solve. Either could be
show-stoppers, but I think we need to focus now on what we can
actually fix without the legal and political BS.
--
Brad Knowles, MIME/PGP: brad@his.com
comp.mail.sendmail FAQ Maintainer <http://www.his.com/~brad/>
finger brad@his.com for my PGP Public Keys and Geek Code
The comp.mail.sendmail FAQ is at <http://www.his.com/~brad/sendmail/>