The question came up in the last stream of what happens if 3DES gets
broken. The answer is that we're in trouble. Any protocol that has a single
MUST algorithm has a single point of failure. Realistically, if that does
happen, on this list (or some other) there will be a flurry of discussion,
and then we'll pick one to be the new MUST algorithm. This would be
painful, but it wouldn't be much more painful than excising out CAST5 or
IDEA. Probably less than IDEA.
I do not believe that we are trying to solve the problem of a bad (or
stupid) person using a bad algorithm and sending you incriminating mail.
There are also algorithm identifiers reserved for experimental and private
algorithms. (And personally, I think the biggest danger is in sending
cleartext mail. The braindead mistake I make at least once a month is to
reply to encrypted mail and not hit the encrypt button -- but that's an
implementation flaw.) If the protocols allow someone to use anything as one
of those and send it around, then you have the same exposure. This is why I
believe that the interpretation of the algorithm preferences that I gave
before is the correct one; it simply makes all of these issues go away.
Now, Bill Geiger's comments are good ones. Any message is a transaction
between the sender and the receiver(s). The protocol needs to address the
sender's desires, and Bill's expressions of them are very close to
arguments that PhilZ has given on this very issue. However, I think that it
is even *more* important to put some control in the hands of the receiver.
The sender has the option of not sending a message if the algorithm
negotiation fails (which would only happen if the sender wants never to use
3DES). As much as the option to use the phone is cold comfort, it is
nonetheless a real option. The receiver has no such option. If the receiver
(irrationally) hates algorithm X yet cannot specify this opinion, there
will inevitably be times when a message encrypted with X will appear in
their inbox. When this happens, the receiver is left in the same position
as Yosemite Sam after a lit stick of dynamite is dropped through the
mailslot. All they can do is snarl, "Ooooooooo! Ya stoopid idjit rabbit, I
told you never to use IDEA!"
The OpenPGP protocol solves the conflicts by declaring that everyone finds
3DES acceptable. Maybe not preferred, but acceptable. To answer Adam Back's
comments, if 3DES is one of your preferred algorithms, you list it to
indicate you like it more than some other algorithm. The question arises as
to whether you'd put it as your *last* algorithm, as it is implicit that
3DES is your least preferred acceptable algorithm. I believe that it is a
good idea to state it. In the previous draft, I asked the question of
whether it is worth having a negative preference on algorithms. No one
seemed to think so. If there were negative preferences, it would be
possible for someone to state a dislike for 3DES, which it is not possible
to do now. If someone were to make a TinyPGP system that used some other
algorithm other than 3DES, then a negative preference could allow it to
interoperate with some OpenPGP implementations. (I'm not advocating that we
do this at all, I'm just nothing that the issue could be solved if we
wanted to solve it.)
I believe that good design of a security protocol means that we should
declare the algorithm prefs to be as I described previously, and that it is
non-conforming to encrypt something to someone using an algorithm not in
their vector. This means that someone who does not implement the
preferences is implicitly commiting to using only 3DES, since it is always
acceptable. If we don't do this, then it is inevitable that a conforming
application will send a message to another conforming application that it
can't decode. And this is a Bad Thing.
Jon
-----
Jon Callas jon(_at_)pgp(_dot_)com
CTO, Total Network Security 4200 Bohannon Drive
Network Associates, Inc. Menlo Park, CA 94025
(650) 473-2860
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA)