[3710] in cryptography@c2.net mail archive
Negotiation (Re: Wassenaar vs. CipherSaber)
daemon@ATHENA.MIT.EDU (Steven M. Bellovin)
Sat Dec 5 11:05:47 1998
Date: Sat, 05 Dec 1998 02:16:10 +0000
To: Raph Levien <raph@acm.org>
From: "Steven M. Bellovin" <smb@research.att.com>
Cc: jim@acm.org, cryptography@c2.net
In-Reply-To: <36688F47.C2BDF392@acm.org>
At 05:41 PM 12/4/98 -0800, Raph Levien wrote:
>1. Eliminate algorithm negotiation. This is something of a pet peeve for
>me. Either you've got secure algorithms or you don't. At worst,
>algorithm negotiation is just another potential security hole -- if the
>attacker can force the choice of a known-weak algorithm, you lose.
>Earlier versions of S-MIME suffered horribly from this problem (replay
>attacks), and for all I know might still. Pick one public key algorithm
>(RSA would be my first pick, but ElGamal has a short term intellectual
>property advantage), one hash (SHA-1), and one symmetric algorithm (3DES
>would be my first pick, although the AES process looks like it will pick
>a winner).
Let me digress here for a moment... I've been thinking a lot about why
negotiation is bad in most protocols, but often seen as necessary for
cryptography. The answer, I think, is that in most cases negotiation
is used to create a slightly (or grossly) different protocol, with different
functionality. In other words, you negotiate when the protocol designers
don't know all possible uses or environments.
Cryptography is different. Cryptographic algorithms "age". That is, due
to faster computers and better cryptanalytic algorithms, an algorithm that
used to be strong will some day be inadequate. Even if the algorithms
are strong, key negotiation has to take place to separate different groups
of users. In other words, for cryptography negotiation is necesssary
to fulfill the base functionality, across both time and space.
