[OTR-dev] OTR encryption state

[Ian Goldberg]

On Thu, Jan 27, 2005 at 01:05:14PM -0500, Greg Troxel wrote:
>     ALWAYS: It is an error to send unencrypted data to this user.
>             If you try, you'll get a notify(ERROR) callback and
> 	    the message to be sent will be turned into an OTR Error
> 	    message that the other side will see.
> 
> I'd say:
> 
>   if one tries to send data, and we don't have a context, try to do a
>   key exchange, and then send the data.  Other than sending KEX
>   request, do not convey any information to the peer.  If KEX fails,
>   notify locally of error.
> 
> I realize that's missing the UI/libotr boundary, though.

I think you'd actually send an OTR Query Message, since you're not
guaranteed at that point that the other side knows about OTR.  But that
seems like a sensible modification.  I think it'd be up to the UI to
have some timeout if it wants to notify the user that the connection
didn't start up.  I think the user should be notify()d in any event,
though.

i.e.:

 - UI tries to send a message to a context that's UNCONNECTED, but
   nevertheless has its policy set to ALWAYS
 - libotr holds on to the message (using the same mechanism as currently
   used for the "bad-encryption" retransmits, as it turns out), and
   replaces it with an OTR Query message.
 - libotr notify(INFO)s the user that it's trying to start a private
   session
 - the UI transmits the OTR Query message it received from libotr (the
   same as it would for any message modified by libotr)
 
 If the other side does not speak OTR, there'll just be a timeout.
 The UI should let the user know.

 If it does, you'll get a Key Exchange message back, which will be
 handled in the normal way.  A private session will start, and the
 original message which triggered this whole thing will get
 retransmitted in the secure session.


What should happen if you receive an unencrypted message from someone
if you're in the UNCONNECTED state, but the policy is ALWAYS?  Maybe
just act like you would if you were CONNECTED?  (i.e. "The following
message received from blah was NOT encrypted: [...]")

   - Ian