Is S/MIME Secure?

Bob Dickinson (bob@deming.com)
Fri, 15 Mar 1996 17:34:52 -0800 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.  Contact your
mail administrator for information about upgrading your reader to a version
that supports MIME.

------ =_NextPart_000_01BB1295.B8C00680
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

All,

    Sorry for not replying to a specific message, but I've been following
the "Clarifying controversial criteria" thread for a while with some
concern.

    First, I will state my affiliation so that my bias will be known in
advance.  I am working on an e-mail product and a security toolkit that
implement S/MIME.  We will look very hard at supporting other protocols
(especially PGP) in the future as the market demands, but for now we are
committed to S/MIME as the protocol that will finally create a "market"
where now we have only "technology".

    My real concern here is not how the criteria will reflect on the
protocol, but how they will reflect on the products that implement the
protocol.  If S/MIME loses on "Secure Interoperability", then presumably
users will be led to believe that products that implement the protocol also
lose.  The argument made by S/MIME detractors is essentially "because S/MIME
is capable of operating in a way that is not completely agreed upon as
secure, then it is not secure".

    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.

    The reason that I think that the criterion may not be useful is that my
concern lies with products and user perceptions, not necessarily with an
academic classification of the protocol.  Since this criterion, as currently
applied, will not be met by ANY product other than a stand-alone PGP
implementation, I question its usefulness.

    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.

    My company will build exportable products that implement RC2 - 40 bit
with 512 bit RSA keys, in compliance with the S/MIME protocol.  We believe,
based largely on the success of similar products using similar exportable
encryption (like RSA Secure), that the exportable product will be successful
in international markets.  

    We will also build domestic products implementing S/MIME that support
Triple DES, RC2 - up to 255 Bits and RSA keys up to 4096 bits.  In these
products, we will be classifying the security available to the end user and
recommending what we believe to be acceptable minimum security levels
(Triple DES or RC2 - 128 bits, RSA keys of 768 bits or greater).  We will
also warn users if they attempt to use security that is weaker than those
recommendations (unless they ask us not to).  Based on all of this, this
group seems to be telling my users that my S/MIME product does not meet the
"secure interoperable" criterion, when if fact, it will very probably be the
most secure and interoperable product available for them to use.

    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?

   Sorry for going on so long, but look at it this way, I probably should
have been submitting several messages a day for the last week arguing these
points (and including several other messages and responses to messages
inline).  This way, if you don't like what I have to say, you only wasted
your time reading one message (albeit, a long one), and you can just hit
delete, put me in your bozo filter, and get on with your life.

Bob Dickinson

    







------ =_NextPart_000_01BB1295.B8C00680--