[OTR-users] Re: [OTR-announce] Flaw in OTR Protocol (with workaround!)

[Ian Goldberg]

On Mon, Jul 25, 2005 at 05:04:27PM -0400, Gregory Maxwell wrote:
> AIM is annoying enough without the overhead of OTR, especially if you
> paste in HTML things, but with OTR it is quite painful.
> 
> Support for compression would help this quite a bit, but I understand
> the desire to avoid compression to make it more trivial to demonstrate
> a modification attack.  ... Since it would still take a lot of work to
> find an AES key that produced the 'right' keystream output given the
> logged traffic. (i.e. in the very likely case that some 'trustable'
> logging device has been installed in the network).
> 
> In any case, message splitting really should be implemented and it
> would be nice if the protocol had support so that there needed to be
> only 1x OTR overhead for a N way split message.
> 
> It would be nice if the splitting mechanism supported joining messages
> of varying length, so that message breaks could be placed randomly to
> frustrate traffic analysis and it would be nice if the maximum message
> length could be controlled based on some feedback from GAIM about what
> it guesses the IM services' rate limit might be.

We talked about this back in December:
http://www.cypherpunks.ca/pipermail/otr-dev/2004-December/000005.html

I'd like to revisit it, though.  The problem the sample implementation
discovered was that the AIM network's bot-flooding-prevention triggered
when the fragments of the message were sent in quick succession.

It turns out gaim makes a half-assed attempt to queue messages that are
being sent too fast, but it contains sections like this:

    /*
     * And now for the meager attempt to force transmit
     * latency and avoid missed messages.
     */
    if ((cur->conn->lastactivity + cur->conn->forcedlatency) >= time(NULL)) {
	/*
	 * XXX should be a break! we don't want to block the
	 * upper layers
	 *
	 * XXX or better, just do this right.
	 *
	 */
	sleep((cur->conn->lastactivity + cur->conn->forcedlatency) - time(NULL));
    } 
    /* XXX this should call the custom "queuing" function!! */
    aim_tx_sendframe(sess, cur);

But in any event, libotr could simply do something like this:

- Callback the app to ask it what the appropriate maximum packet size
  should be for the given buddy.  The app may return a size in bytes, or
  0 for "no fragmentation".
- The app's inject_message callback must deal with any network-specific
  bandwidth limits.


Having fragmentation work would simplify a number of things, so I think
we might try again.  There's still the big issue of how to determine
what the correct maximum packet size should be, and I don't know of a
good way to do that (see the above thread).  Hardcoding some values
is a kludgy workaround.  Making those values user-configurable at least
allows user fixes if the networks change.  Any other suggestions?

   - Ian