Re: Security Problems
Brad Knowles (brad@azathoth.ops.aol.com)
Mon, 4 Mar 1996 14:30:03 -0500
On Mar 4, 12:26am, Terry Ritter wrote:
> 1. Announcing in open headers that a message is in cipher is a
> serious security problem. At certain times and places simply
> sending such a message could be a dangerous activity.
If all you get is a 7-bit clean file and are told nothing else
about it, how do you tell what to do with it? How do you know if it's
a video? How do you know if it's an audio message? How do you know
if it's encrypted?
There is a certain minimum amount of information regarding the
nature of the content that must be left in the clear (either human
readable or machine readable), otherwise you have no way of knowing
what kind of data it is and how to handle it.
If I give you a message that is encrypted and tell you absolutely
nothing about the encryption method, even if you are the intended
recipient, then you might as well be someone other than the intended
recipient, because you'll end up having to apply all the same
cryptographic techniques to decipher the message as someone who had
surreptitiously managed to get a copy of the ciphertext.
> Cipher selection can be negotiated between both parties.
> (I note that cipher selection negotiation was the way ANSI X9F3
> was going in early 1994, and may still be, for all I know.)
> Typically, we use Triple-DES until agreement is reached. Ciphers
> are identified by a name assigned by the designer or manufacturer,
> thus avoiding the need for a central registry. Many private
> key ciphers can be interchanged simply by giving each a similar
> envelope for init, encipher, and decipher functions. (Key
> distribution is at a different level and irrelevant to this
> sort of cipher selection.)
How do you negotiate encipherment in an email message? Do you
want to be kept online waiting for the negotiation to take place? Do
you want to wait five days for the initial negotiation message to time
out and bounce?
This is a store-and-forward technology. There is absolutely
*nothing* guaranteed about the timely delivery of the message other
than if it arrives, it will arrive sometime after you sent it. You
cannot, you *must* not make the delivery of secure Internet email
dependant on some external method of negotiating encryption
methodology (in part because you can't guarantee that some sites will
have anything *but* email), and you can't afford to wait for the
in-band methods to complete.
There has to be a minimum starting point defined by the standard,
and hopefully there would be some official method for extending that
registry.
> My approach is to allow a different cipher in each direction.
> The sending side sends a list of ciphers it can use; the
> receiving side makes a selection and sends the selected name
> to the sending side. The next message from the sending side
> is in the newly-selected cipher. (Or negotiation continues.)
> The other direction performs similarly.
That's an online transaction-processing model. Email is not
online transaction-processing. It is store and forward. Therefore
this basic assumption fails. In the case of HTML, if it can't be
secured by some sort of negotiation of this sort, then presumably you
don't want it to happen at all. But would you want your email to
completely fail if the multi-day turn-around time of the negotiation
attempts fail?
Would you want the potential data loss of one side listing all
the algorithms it supports? No. For security purposes, it is vitally
important that each side have it's list of preferred or available
encryption techniques available to it, but since it can't trust the
other side, it needs to make sure that it divulges as little
information as physically possible regarding what it is capable of to
the other end, while still allowing secure communications to take
place.
--
Brad Knowles MIME/PGP: BKnowles@aol.net
Mail Systems Administrator <http:www.his.com/~brad/>
for America Online, Inc. Ph: (703) 453-4148