From: Raph Levien <raph@c2.org>
Date: Sat, 24 Feb 1996 16:18:31 +0800
To: resolving-security@imc.org
Subject: No Subject
Message-ID: <199602230055.QAA15846@infinity.c2.org>
MIME-Version: 1.0
Content-Type: text/plain


   Here follow one cypherpunk's impressions of the Internet Mail
Consortium's Security Workshop
(http://www.imc.org/security-workshop.html) on Wednedsday 21 Feb 1996.
Since there will be official notes of the proceedings, I felt I had a
little more scope to convey mood and feelings rather than dry
technical facts. After all, I think the buzz will do more to determine
what gets deployed than the technical merits.
   This document is available on the Web at:
      http://www.c2.org/~raph/report.html


The setting
-----------

   Paul Hoffmann and Dave Crocker recently started the Internet Mail
Consortium (http://www.imc.org). This workshop was its first major
activity. Dave Crocker moderated the event, skillfully herding almost
70 secure email proponents and representatives from user communities
through a very tough subject.
   The title of the workshop was "Resolving email security," but there
was no real expectation that the issues would be resolved that day.
What was expected (and what happened) is that people would get a
better understanding of why secure email hasn't happened yet, what
kinds of things could be done to make it happen. More impressively,
there was "room consensus" for a few _very_ positive steps, about
which more later.
   One of the goals of the IMC is to involve users, not just
developers. I was ready to "officially" represent the "cypherpunk user
community," but fortunately, I didn't need to. In fact, the strongest
advocacy of strong crypto came from an employee of a "large service
provider in America." Overall, I felt that the user communities were
pretty well represented, and all important technical points got made.


MOSS is dead, long live MOSS
----------------------------

   There were five contenders on the field going into the day, and two
and a half at the end. MOSS was one of the casualties. A lot of us
were sorry to see it go, but eliminating candidates has got to happen
if we're going to have interoperation.
   It's hard to say exactly what went wrong. MOSS had many advantages,
and was a nice, clean, pretty standard. I think what doomed it was the
lack of a good implementation.
   Even though MOSS is no longer considered a serious contender, one
piece of it is still very much alive: the multipart/signed message
format. At the end of the day, there was strong, nearly unanimous
consensus that multipart/signed should be recommended as the signed
message format for _all_ of the email encryption protocols.


S/MIME: you can dance to it
---------------------------

   There was a lot of energy around S/MIME. People are implementing
it. Internally, it's pretty kludgely, but it does provide pretty good
cryptographic services. (as an aside, my favorite kludge anecdote is
the fact that X.509 certificates use an IA5 character set rather than
ASCII, so that the @ in email addresses has to be represented as (a)
instead).
   The main thing people didn't like about the existing S/MIME spec is
the signed message format. In the existing spec, you've got a choice
between a message unreadable to non-S/MIME-aware clients, or
duplicating the data. Neither alternative is very palatable.
   Apparently, though, a new version of the S/MIME spec _will_
incorporate the multipart/signed format of RFC 1847. This made almost
everybody happy, although I'm sure all those S/MIME developers are a
bit unhappy with the spec changing, and having to reimplement stuff.
   The biggest problem with S/MIME is that the signed and encrypted
format reveals who made the signatures. Obviously, this has severe
consequences for anonymous mail. Believe it or not, a lot of people
care. For example, the car manufacturers do not wish to broadcast the
email addresses of their employees over the net.
   One technical workaround is to do it the MOSS way - first, sign the
message, resulting in an intermediate S/MIME message, then encrypt
that into a second S/MIME message. I'd recommend that implementors
make provisions for such recursive formats; I think it's likely that
we'll see a lot of these on the Net.


PGP: troubled, but still alive
------------------------------

   The consensus was that S/MIME and PGP/MIME are the two viable email
encryption protocols. Thus, PGP is still very much alive and kicking.
   PGP's fabulous strength is that it won't let you down
cryptographically. That simply cannot be said for the other
contenders.
   That said, much about the PGP effort troubles me. Perhaps the
biggest problem is that there just aren't enough people working on it.
>From what I understand, it's pretty much just Derek and Colin, and
there's a _lot_ of work to do. I said before that I didn't think the
public PGP/MIME release will happen until this fall, and I see no
reason to change my estimate. By that time, a lot of S/MIME
implementations will already be deployed.
   One strength of PGP has traditionally been its unity. PGP means one
message format (the PGP one), one suite of crypto algorithms (the PGP
one), one key format (the PGP one), one application (PGP itself). Most
of the other proposals are modular in some way, especially with
respect to algorithms. PGP is moving in that direction.
   The most visible evidence of that is the way PGP/MIME is being
done. The prevailing philosophy of the PGP people is that the PGP
application itself should not decode MIME formats - that should be the
job of a separate application. It seems to me that this is going
against the tradition, though. In the past, if you got a PGP message,
you just ran it through PGP. Now you won't be able to do that.
   Also, the existing data formats (while pretty good) are going to
get changed. The algorithms are going to "go modular" (although I
don't think we'll be seeing a Fortezza implementation any time soon).
This is going to cause a lot of pain for the installed base. Will it
be worth it? We'll just have to see.


MSP: not as bad as you think
----------------------------

   Earlier, I mentioned that two and a half protocols survived the
day. The remaining one is MSP. It's actually not a bad protocol. It
has two features that none of the others have: the ability to label
classified messages, and a cryptographically strong signed receipt.
Both of these functions are highly important for government users. It
looks like government suppliers are going to go ahead and implement
it, and the government is going to use it.
   MSP has been around a while, but the effort to turn it into a
serious alternative for general Internet use is quite new. Two specs
got published this month: a MIME integration spec (sharing the same
problems as the old S/MIME), and a spec for plugging in the RSA
algorithm suite. With these specs in place, MSP would not be
fundamentally that different than, say, S/MIME.
   My feeling is that the main differences are cultural. MSP still has
a very ASN.1, OSI, governmental flavor. Its proponents are making the
effort to be responsive to users, but I think there's still a bit of
skepticism about that, perhaps misguided, perhaps not.
   It was announced that there will be a free reference implementation
of MSP, available to US citizens.


My kingdom for 40 bits
----------------------

   I've been thinking about the 40 bit thing a lot. It makes me very
uncomfortable. From the cypherpunk perspective, this should be nothing
new or remarkable, but keep in mind that there's a _lot_ of pressure
on companies to be able to make money in overseas markets.

   In one of the "modular algorithms" designs, it's not easy to figure
out which algorithms your recipient can understand. Guess wrong, and
your message goes out with 40-bit encryption. In my opinion, this is
worse than no encryption at all, because it gives the false sense of
security. Building such a failure mode into an email encryption
protocol strikes me as a bad idea.

   This is my subjective impression, but I sensed that there was a
collective delusion that US software developers would actually be able
to sell a 40-bit product overseas. Certainly, Netscape has proved that
it is possible, but then again, encryption is peripheral to the value
of their product. You'd still be using Netscape even if it had no
encryption at all, wouldn't you? How many https: URL's are even in
your history.db file? For a "secure email" product, it's a different
story.

   There were a few other things that led me to the conclusion of a
40-bit delusion. First, people still seemed to thing that the
cypherpunk 40-bit cracks were a concerted effort by highly expert
people, rather than the weekend hacks that could be duplicated by any
competent sysadmin or grad student. I don't think the message really
got through. If 40-bit email gets deployed, we need to make a few more
high-profile cracks just to hammer it in.
   Finally, there's an almost religious belief that making the choice
of algorithms indepenent of the encryption protocol will somehow solve
the problem. From the point of view of the user, this is just not
true. What the user selects is an encryption protocol, an algorithm
suite, and whatever other parts of the spec were left open. What the
user selects doesn't have any modularity in it at all. It's either a
good protocol or a bad one.

   Maybe customers today think that 40-bit encryption offers some
value, but I think they'll soon be disillusioned. This is something
that cypherpunks can have a role in. In the medium to long term, it
will become clear that 40-bit encryption offers no benefits, and in
fact is dangerous.
   My advice to US developers: don't even try to export a 40-bit
version of your product. Just leave crypto out of the export version.
Your product will have better performance and many fewer configuration
problems. Include 40-bit in the US product if you have to, but don't
allow it to be used silently. For example, put up a little dialog that
says, "are you _sure_ you want to use 40-bit encryption? It's not
secure, you know."
   If care about offering crypto in the non-US market, form a
partnership with overseas developers to add the crypto.

   Non-US developers, now is a fabulous opportunity. Get those
implementations underway, the sooner the better.


Coexistence
-----------

   Since there is no one single standard that everyone feels
comfortable with, we will somehow have to deal with the coexistence of
multiple conflicting protocols. Fortunately, this is something the Net
is good at.
   Most serious email vendors plan to "implement everything that's
real." That means S/MIME for sure, PGP/MIME assuming they can get
their hands on a decent implementation, and MSP if they sell a lot of
stuff to the government.
   If everyone follows this path, then we really will have
interoperable secure email. Perhaps over the long term, one of the
standards would come to dominate, perhaps not.
   I know that the deployment of secure email has been a year away for
the past decade or so, but now I think it really is poised to happen.
The implementation effort is very much real. Over the next few months,
we will see some very high profile, mass market implementations.
   Before that happens, though, the protocols must actually become
stable. It's a characteristic of _all_ of the viable protocols that
they're still in flux, still in the process of being defined. But at
least the direction is clear, largely as a result of feedback from
this workshop.


Consensus
---------

   At the end of the meeting, Dave asked the room for consensus on
several points. First, there was strong consensus that the encryption
protocols converge on multipart/security for their signed message
format. Second, it was agreed that the proponents of the surviving
schemes get together to list their differences, justify these
difference, and commonalize things that don't _need_ to be different,
also agreeing on a timetable concluding at the Montreal IETF meeting.
   I'd say that's quite a remarkable achievement for a such a
difficult area.

Raph Levien