Comments on IETF-EDIINT security decision matrix

• Messages sorted by: [ date ][ thread ][ subject ][ author ]
• Previous message: Ian Duncan: "Re: MIME Security with PGP"

(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

• Previous message: Ian Duncan: "Re: MIME Security with PGP"