Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!caen!zaphod.mps.ohio-state.edu!rpi!batcomputer!munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!fang!se2!sxc
From: sxc@se2.dsto.oz (Stephen Crawley)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Certified Mail Systems...
Message-ID: <1421@fang.dsto.oz>
Date: 27 Feb 91 20:03:07 GMT
References: <B47A485D5BFF012862@vax1.umkc.edu>
Sender: news@fang.dsto.oz
Lines: 79

PH461A04@VAX1.UMKC.EDU (Guerra de Bureau) writes:
>Regarding a protocol for SMTP certified mail, can anyone suggest
>why the following procedure would not work??
>	1) Local mail system encrypts mail with time-varying key
>	2) Local system forwards mail to remote system
>	3) Remote system delivers (encrypted) mail to designated user
>	4) Designated user requests key from remote system
>	5) Remote system requests key from local system
>	6) Local system indicates to message originator that message
>	   has been received and key requested.
>	7) Local forwards key to remote
>	8) If remote system does note recieve key withing (x) units,
>	   repeats request for (y) tries before informing recipient key
>	   unavailable
>	9) Remote delievers key to remote user/unencrypts original message

>The only failure that I see is if a) the remote system requests the
>key from the local system; b) the local system acknowledges the request,
>and c) the anknowlegment(key) never gets back to the remote, and finally
>d) the remote is not able to re-request the key within the designated
>time frame.  Given the increasing network reliability and the decreasing
>network transfer time and a sufficient number of retries/length of
>time before discard this system would seem fairly secure.

>Any problems??

If we assume that the network is insecure, I can think of three
security problems with your proposal.

First, a third party (call it "spy") can read mail sent from "local"
to "remote".  Here is how:
   
   When "local" send the encrypted mail message to "remote", "spy" grabs
   a copy of the message.  When "remote" requests the key, "spy" grabs
   the reply message from "local" and uses it to decrypt the message
   at his leasure.

Second, "spy" can fool "local" into thinking that a message has been
delivered when this is not the case.  This is how:

   When "local" tries to send the encrypted mail message to "remote", "spy"
   intercepts it and sends a request to "local" saying "I'm remote; what's 
   the key".  "local" responds with the key, and tells the sender that the
   mail has been delivered.  In fact, the message has black-holed.

Third, "spy" could prevent "remote" from reading mail messages, by grabbing
the messages containing the decryption key.  For ultimate maliciousness,
it could forward the messages with garbled keys!

The root causes of these problems are:
  1)  The decryption key message is sent in clear.  
  2)  Key request and replies cannot be authenticated as coming from
      the right place.


In addition to the security issues above, there are a number of more
mundane problems.

  1) The use of timeouts and timestamps means that the protocol is likely 
     to fail when certified mail and/or key messages are relayed through 
     a slow or flakey mail gateway.

  2) The "local" system has to keep a record of the keys for each certified 
     message sent.  It is not obvious how long this information needs to be 
     kept.

  3) The mail message is sent only once.  If it gets lost, the sender
     loses.  He/she can't distinguish that case from the recipient not
     having read the message.

  4) The notification to the sender of a key request does not tell
     him that the recipient has been able to read the mail.  If
     the decryption key fails to arrive, this will be impossible.


-- Steve


    


Brought to you by Super Global Mega Corp .com