Re: Comments on IETF-EDIINT security decision matrix
Dave Darnell (dave_d@systrends.com)
Tue, 04 Jun 1996 15:42:51 -0700
Raph,
I really appreciate your feedback -- excellent info!
In fact, Rik and I were talking on the phone about some of this just this
morning.
Your item 5. is especially helpful in that I suspected the same of the
S/MIME spec:
>5. Section 26 (adequate security for EDI purposes) has
>S/MIME and MOSS reversed. MOSS does _not_ have the problem
>that encrypted-only and encrypted-and-signed messages can be
>distinguished. S/MIME is the one that has that problem. In
>fact, the problem is quite a bit worse: it is possible to
>determine the identity of the signatories in S/MIME
>encrypted-and-signed messages. This could be a serious
>problem for EDI applications.
>
I agree - IMHO - THIS IS A SERIOUS PROBLEM FOR EDI APPLICATIONS!
Please clear up something for me:
I thought PEM had this problem also. Was this fixed in the MOSS spec?
Is my information wrong about PEM?
Appreciate any further comments you can contribute.
Regards,
dave_d
At 12:14 PM 6/4/96 -0400, Raph Levien wrote:
>(this is a cc: of feedback submitted by Web to the IETF)
>
>The comparison chart
>(http://ftp.sterling.com/edi/ietf-ediint/decision.html)
>basically looks good. Obviously, it has benefitted from IMC
>discussion in addition to work in the EDI community.
>
>However, I found a few problems with it.
>
>1. You seem to be under the impression that PGP 3.0 will
>support PGP/MIME directly. From my discussions with the PGP
>development team, I believe this is unlikely to be the case.
>They are struggling to get even minimum PGP functionality
>into the 3.0 release, and (in my opinion) are seriously
>underestimating the importance of MIME. Thus, people using
>PGP/MIME will want to plan on their own implementations of
>the PGP/MIME spec.
>
>2. The listing for PGP in section 12 implies that there is
>a 1024 bit limit for RSA key sizes. In fact, the limit in
>the current version of PGP is 2048 bits.
>
>3. The listing for S/MIME in section 13 states that
>multipart/signed support is optional. I believe that it is,
>in fact, required by the latest version of the S/MIME spec.
>This applies also to section 15 and 18 (should be Yes in
>both, is "No" and "Yes, optional", respectively).
>
>The S/MIME implementation guidelines document has not been
>revised recently enough to specify whether multipart/signed
>support is required or merely recommended. However, it is
>required by the interoperability test procedures, so I'd say
>it's reasonable to consider it a done deal.
>
>4. premail is missing from PGP/MIME's current implementation
>status. In the same box, I would estimate that 3Q96 is an
>overly optimistic date for PGP 3.0.
>
>5. Section 26 (adequate security for EDI purposes) has
>S/MIME and MOSS reversed. MOSS does _not_ have the problem
>that encrypted-only and encrypted-and-signed messages can be
>distinguished. S/MIME is the one that has that problem. In
>fact, the problem is quite a bit worse: it is possible to
>determine the identity of the signatories in S/MIME
>encrypted-and-signed messages. This could be a serious
>problem for EDI applications.
>
>I believe that DMS has the same problems, but I am not sure.
>
>The S/MIME people have expressed a willingness to consider
>changes to the S/MIME spec that would allow this problem to
>be overcome. I believe that the correct way to do this is to
>change the implementation guidelines so as to recommend or
>require that recievers are capable of decoding signed
>messages wrapped inside encrypted-only messages, in addition
>to encrypted-and-signed messages. This would allow the
>sender to dictate the policy of whether the identity of the
>signatories is revealed.
>
>6. Although this is not explicitly addressed in the chart,
>I would like to call your attention to the importance of
>default keysize and algorithm selection. As presently
>specified, S/MIME defaults to 40-bit RC2 encryption, even
>if both sender and reciever clients are non-export versions.
>At present, the only way to get better algorithms is to
>manually configure the clients, an error prone and
>potentially confusing task. Further, in fully automated EDI
>settings, manual configuration may not be feasible.
>
>There are two proposals floating to address this problem.
>The first is to specify an extension to the S/MIME message
>formats or X.509v3 certificate formats by which a client can
>advertise its algorithm capabilities. I support this
>proposal, but with two reservations. First, since it is not
>yet specified, it will fail to work with existing clients.
>Second, it is not clear that the "advertising" process will
>be sufficient to cover all transmissions. For example, if
>the advertisement is included in signed message formats (as
>are X.509 certs), then the first exchange of messages will
>use a weaker default algorithm.
>
>The other proposal is to choose algorithm and keysize based
>on the public key size of the recipient. In this proposal,
>the default encryption algorithm would be 64-bit RC2 if the
>recipient's public key is 512 bits or less, otherwise
>168-bit Triple-DES (i.e. DES-EDE3-CBC). This policy has the
>advantage of not causing any interoperability problems (in
>light of the recently unveiled policy on S/MIME
>exportability), as well as being fully backwards compatible
>with existing clients. Therefore, I am pushing as strongly
>as I can for its adoption.
>
>The two proposals are not mutually exclusive, and both can
>in fact be implemented.
>
>Thanks for providing this opportunity to give feedback.
>
>Raph
>
>Cc: resolving-security mailing list
>
>
======================================
| David Darnell
| SysTrends, Inc.
| Arizona EC/EDI Roundtable
| 1850 East Carver Road
| Tempe, AZ 85284
| Tel (602)838-5316
| Fax (602)897-8032
| mailto://dave_d@systrends.com
======================================