On Thu, 15 Feb 1996, James M. Galvin wrote:
Very nice comparison. I didn't find your comments overly subjective but
rather a statement of experience. I have two comments.
Thanks.
At 4:49 PM 2/14/96, Raph Levien wrote:
MOSS is mostly cryptographically sound. However, the choice of
symmetric encryption algorithm (and key size) is left unspecified.
It is true that the MOSS specification itself does not state which
algorithm to use or its recommended properties. Instead, we continued with
the model PEM established and left the specification of the algorithm as a
separate document: RFC1423. Thus, MOSS does specify RSA and DES, which
fails your criteria for minimum key size, but that is easily fixed.
They're not just my criteria for key size, they're the criteria of a
star-studded cast of some of the most famous cryptographers and security
experts on the planet.
I really don't care how easily fixed this problem is. I care about
whether what gets deployed is cryptographically strong. If we're going to
implement a system that can be cracked for $38 per key, then why even
bother? The alternative of no cryptography at all starts to look mighty
appealing - no compatibility problems, no export restrictions, no key
database, no performance problems, etc.
I stand by my original assessment.
Perhaps the biggest feature required in the mailer is integration
of key management and the "address book". If this feature is not
implemented in the mailer, then two address books are required - one
to select email addresses, and another to map email addresses to keys.
This approach is used by premail, and is the source of many usability
problems. It would be nice if a database existed which could map email
addresses to public keys without manual intervention, but none of the
proposals on the table are capable of it.
In point of fact, MOSS supports this feature. The email address name form
was included precisely because we figured people would want to continue to
use names with which they were familiar. Further, the email address could
be parsed and the DNS could be used to lookup the public key.
In the TIS/MOSS implementation, it is possible to lookup public keys based
on any data stored with that public key, including the email address.
There are issues with respect to the uniqueness of the name form, but you
could enforce simplifications if you want (my opinion).
I chose my words poorly. What I meant to say is that none of the
proposals can map an email address to a public key without the use of a
manually maintained database.
DNS? Are you suggesting that the public key be stored within the DNS
database? The idea is nice, but DNS as deployed today is far too
insecure (see the Wall Street Journal, 9 Feb 1996 for an example).
I'm thinking now that I should have addressed the problem of the key
database in my original review. Technically, it's orthogonal to the
bits-on-the-wire specification of the protocol, but it's equally important
to standardize in practice.
All of the protocols provide for both manual maintenance, and in most
cases, some kind of automatic or semi-automatic assist. In my experience,
it is not possible for this procedure to be fully automatic; at some
point, the user has to make a decision about which keys are trusted and
which keys are not.
My argument is that the protocol should facilitate making this process
as easy and quick as possible. One application which has, in my opinion,
got this exactly right is Netscape 2.0. When presented with an untrusted
certificate, it pops up a dialog box containing all the human-readable
information in the certificate, as well as a "certificate fingerprint,"
which is just the MD5 hash of the certificate, if I remember correctly.
Then, you have a choice between allowing or not allowing connections to
the site, and warning or not warning before sending data to the site. Go
to the Options|Security menu, and click on "Site Certificates" to try
this out yourself
Considering that the user has to maintain this trust information
manually, a certificate fingerprint is the most user-friendly way to do
it. I can call up the site on the telephone and ask them for the
fingerprint. They could print it in their brochures, put it on business
cards, or whatever. However, these channels are _not_ good for anything
bigger than a few dozen hex digits.
I should point out that none of the protocols do a good job with this
one. PGP has three ways of naming keys: a "fingerprint", the 8 least
significant hex digits of the modulus, and the user id. The fingerprint
contains a cryptographic weakness, meaning it is quite straightforward to
generate collisions in all three namespaces. Even if the fingerprint were
sound, then it still can't be used by PGP 2.6 as an index into the key
database. As a result, the responsibility falls squarely on the user to
keep the database free of name collisions.
This is one of the big pains in the posterior when working with PGP.
Most people don't understand the problems, and so their management of the
key database is sloppy. To my knowledge, a bogus key attack has not been
mounted against PGP, but if it were, I believe the confidence in PGP could
be sorely shaken.
My recommendation is that every one of the email protocols supports a
standardized cryptographic has of the public key, so that when the time
comes to ask the question "Do you, the user, trust this key?", the user
has some idea what key is being referred to. On the cypherpunks mailing
list a few months ago, I gave the specific proposal of using the MD5 hash
of the MOSS representation of the public key including the "PK," prefix,
but with all whitespace eliminated. I feel that this is a concrete
proposal, and easy enough to implement, both for MOSS and PGP.
Raph