Issues with S/MIME Message Specification

"Robert R. Jueneman" <bjueneman@novell.com> Tue, 18 May 1999 19:52 UTC

Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15150 for <smime-archive@odin.ietf.org>; Tue, 18 May 1999 15:52:05 -0400 (EDT)
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA17355 for ietf-smime-bks; Tue, 18 May 1999 11:35:56 -0700 (PDT)
Received: from orm-mail20.orem.novell.com (orm-mail20.orem.novell.com [151.155.118.32]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA17349 for <ietf-smime@imc.org>; Tue, 18 May 1999 11:35:24 -0700 (PDT)
Received: from bobjuenemannt (stevecarroll.dnsdhcp.provo.novell.com [137.65.212.77]) by orm-mail20.orem.novell.com; Tue, 18 May 1999 12:34:31 -0600
Reply-To: bjueneman@novell.com
From: "Robert R. Jueneman" <bjueneman@novell.com>
To: The IESG <iesg-secretary@ietf.org>
Cc: RFC Editor <rfc-editor@isi.edu>, ietf-smime@imc.org, "Robert R. Jueneman" <bjueneman@novell.com>
Subject: Issues with S/MIME Message Specification
Date: Tue, 18 May 1999 12:34:32 -0600
MIME-Version: 1.0
Message-ID: <006701bea15d$124b2e60$4dd44189@provo.novell.com>
X-Priority: 3 (Normal)
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0052_01BEA118.F1833EF0"
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <199905171126.HAA17249@ietf.org>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-ietf-smime@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

I sincerely regret not having had sufficient time to review the S/MIME v3
specs in detail during last call and prior to their moving to Proposed
Standard, but I believe that there are several changes that absolutely
must be made before they can progress to final Standard.

Regarding the S/MIME Version 3 Message Specification,
draft-ietf-smime-msg-08.txt, I believe that all MUSTs and SHOULDs
regarding specific cryptographic algorithms should be removed from this
document, and contained only in the Cryptographic Message Syntax document.
I can see no reason at all why such things should be specified twice -- it
just makes conformance checking all that much more difficult.  An example
of this kind of difficulty is para 2.2 of the S/MIME Message
Specification, which says that sending and receiving agents SHOULD support
rsaEncryption, whereas the Cryptographic Message Syntax , para 12.2, says
that CMS implementations "may" support RSA.  Neither mentions RSA with
OAEP.

This affects section 2.1, 2.2, and 2.3, and most emphatically section 2.7,
"ContentEncryption AlgorithmIdentifier", and 2.7.1.3 "Rule 3, Unknown
Capabilities, Unknown Version of S/MIME."

Without getting into international politics, at the present time
triple-DES is not exportable from the US, at the very least, and may very
well not be importable into some other countries.  Specifying that S/MIME
agents MUST implement triple-DES therefore presents a vendor with Hobson's
choice -- they can either chose not to be compliant with the RFC, or they
can chose not to export their product.  Unfortunately, that is no choice
at all -- any sane US vendor will choose not to be compliant with the RFC,
rather than lose perhaps 50% of their market.  The only purpose such a
red-flag-in-front-of-the-bull statement serves, therefore, is a political
one, and one that will merely lower the credibility of the IETF and the
IESG in the vendor and business community.  At most the requirement should
be SHOULD.

The second part of 2.7 specifies that receiving agents SHOULD support
RC2/40 "or a compatible algorithm at a key size of 40 bits..." This
recommendation suffers from two major problems, in my view. First, it is
LESS secure than 56-bit DES, which is now acceptable world-wide (with
perhaps one or two minor exceptions -- not quite clear) for data
encryption.  And second, it is a proprietary, trade-secret algorithm.  Not
only is that contrary to the general direction of the IETF in not
mandating proprietary algorithms, but the fact that it is a trade secret
(not withstanding the fact that it has been reverse engineered) means that
there has not been adequate attention paid to its security in the academic
cryptanalytic community.  RC2 of any size may well be worth considering
for support, and might deserve RECOMMENDED status, but that should be up
to the vendor.  If RC2 is required for backwards compatibility with S/MIME
v2, then a paragraph noting that fact would be appropriate, as was
provided as the last paragraph under 2.3 ("Note that S/MIME v2 clients are
only capable of decrypting content encryption keys using the rsaEncryption
algorithm.").

(I am taking this position with no lack of respect for Ron Rivest, whom I
consider a very able cryptographer.  But I would take that position if God
Herself had invented but not published some particular algorithm.)

With respect to 2.7.1.3, there are two problems. First, it mandates
triple-DES, which very well may not be available at to the recipient, and
secondly, it recommends as a fall back position the use of the
trade-secret RC2/40.  Both statements should be removed. The CMS
specification should then develop a list of algorithms in rough order of
strength, to be used for such negotiations as required.

Finally, somewhere in these documents there is a statement regarding the
advisability of including the content encryption key encrypted in the
originator's public key, but despite rereading the documents multiple
times I can't find that text again.  As I recall, the text said that this
SHOULD be done.  I would argue that this should be changed to MUST, for I
can't imagine a situation where the originator of an encrypted message
would not want to be able to read his own message, for example in an
outgoing or Sent-Mail queue. He might need to be able to decrypted, and
even retract it in order to resend it with modifications.  It would not be
reasonable to rely on the originator to bcc herself to gain this
capability -- it ought to be required by the spec.

I will be addressing my concerns with the CMS specification in a
subsequent message.

Bob

---------------------------
Robert R. Jueneman
Novell, Inc.

(See digital signature DISCLAIMER in attached vCard)

>-----Original Message-----
>From: owner-ietf-smime@imc.org [mailto:owner-ietf-smime@imc.org]On
>Behalf Of The IESG
>Sent: Monday, May 17, 1999 5:26 AM
>To: IETF-Announce: ;
>Cc: RFC Editor; Internet Architecture Board; ietf-smime@imc.org
>Subject: Protocol Action: Cryptographic Message Syntax to Proposed
>Standard
>
>
>
>
>The IESG has approved publication of the following Internet-Drafts as
>Proposed Standards:
>
> o Cryptographic Message Syntax <draft-ietf-smime-cms-13.txt>
> o Diffie-Hellman Key Agreement Method <draft-ietf-smime-x942-07.txt>
> o S/MIME Version 3 Certificate Handling <draft-ietf-smime-cert-08.txt>
> o S/MIME Version 3 Message Specification <draft-ietf-smime-msg-08.txt>
> o Enhanced Security Services for S/MIME <draft-ietf-smime-ess-12.txt>
>
>These documents are the product of the S/MIME Mail Security Working
Group.
>The IESG contact persons are Jeffrey Schiller and Marcus Leech.
>
>
>Technical Summary
>
>These documents describe Version 3 of S/MIME (Secure/Multipurpose
>Internet Mail Extensions). S/MIME provides for the secure
>communication of MIME Objects, providing Authentication, Integrity and
>Confidentiality protection. It can be used wherever MIME is used, as
>it is fully conformant with the general MIME specifications. The
>documents here provide for the basic message syntax and semantics as
>well as the certificate and key management infrastructure
>required. This work is coordinated and builds upon the work of the
>IETF X.509 Public Key Infrastructure Working Group (PKIX).
>
>In addition to the basic security services mentioned above, several
>optional services are described. These include signed receipt
>handling, security labeling of objects, secure mailing lists and
>signing certificates.
>
>Working Group Summary
>
>The working group came to consensus on the work described here. A lot
>of people contributed thoughtful, useful and constructive comments
>during the review periods which resulted in further improvements
>reflected in these documents.
>
>Jeffrey I. Schiller reviewed the specification for IESG.
>
>