[OTR-dev] irssi-otr 0.1 released

[Uli M]

On Wed 16.07.08 08:34, Ian Goldberg wrote:
> On Tue, Jul 15, 2008 at 11:08:00PM +0000, Uli M wrote:
> > On Tue 15.07.08 17:31, Ian Goldberg wrote:
> > > On Tue, Jul 15, 2008 at 03:25:30PM +0000, Uli M wrote:
> > > > IIRC bitlbee splits IRC messages longer than 512 bytes (note that an IRC
> > > > message also contains other stuff like nick and server, so the actually
> > > > payload should be less than that). I can be very thankful for that
> > > > because irssi-otr wouldn't exist if bitlbee would cut the messages off
> > > > (which I'm sure some IRC servers do). By splitting I mean making two
> > > > messages out of it, so for example
> > > > 
> > > > :nick!nick at irc.server.net PRIVMSG ulim : FOO.........BAR.......
> > > > 
> > > > becomes
> > > > 
> > > > :nick!nick at irc.server.net PRIVMSG ulim : FOO.........
> > > > :nick!nick at irc.server.net PRIVMSG ulim : BAR.......
> > > > 
> > > > How does irssi-otr detect and reassemble this:
> > > 
> > > Ah, I see.  So there's no actual framing, saying "this is fragment 1/3"
> > > or anything like that.  I guess what you're doing is about all you can
> > > do, in that event.
> > 
> > Yeah, the whole thing is only a workaround. The real problem is that the
> > MMS on the other end is too high for IRC.
> 
> And that's because the other end thinks it's talking XMPP?  It doesn't
> know that the buddy is actually on IRC?

Nope, bitlbee is a transparent IM-to-IRC gateway. The ICQ/Jabber/AIM/...
end doesn't know that bitlbee is on the other end and the IRC end could
know it (if someone told it how to recognize bitlbee) but doesn't need
to know ;) And my assumption is that this situation(one end not knowing
the MMS capabilities of the other) is not unique to bitlbee - but maybe
I'm wrong.

> > Which wouldn't be the case if
> > libotr chose the smaller MMS of the two peers on both ends. I imagine an
> > additional field for the MMS in the initial message exchange would
> > suffice. Or maybe even in the query message...something like
> > ?OTR?MMS=416. Then all the other end has to do is compare its value and
> > choose the smaller number.
> 
> Unfortunately, the latter is too ugly, even for me.  :-) 

OK, I agree the query message isn't a very good place for it ;)

> Not to mention that it would be nice if the MMS value were
> authenticated.  And the former doesn't quite work, since the initial
> key exchange messages themselves need to be fragmented on IRC.

Well since the MMS doesn't affect the generation of the encrypted
messages themselves but only how they are delivered from A to B (as I
understand it) I imagine it isn't much of a security risk. If that's
true including it in the initial exchange wouldn't hurt. 

Another option would be to always use a low enough MMS for the initial
exchange and when the connection is authenticated agree on a higher MMS.

> > Such a change probably wouldn't be reasonable just for irssi-otr but I
> > can imagine that this problem arises in other contexts where gatewaying
> > or proxying is done as well.
> 
> I guess the question is what delivery claims is bitlbee making?  

Well it can't really offer more than the underlying protocol which
offers messages of up to about 500 bytes length (exact amount depends on
how you count). As RFC 1459 and RFC 2812 state 

	"There is no provision for continuation of message lines."

so from the standards perspective that is all you have.

> It's performing fragmentation, but it looks to me like it's up to
> every IRC client to do the defragmentation.  

Seeing that there is no method for fragmentation in IRC bitlbee does the
only sensible thing to do with overlong messages: it splits them up
(fragmentation is a very nice word that ;) ). And I'm sure the developer
who wrote that never thought an IRC client would want to reassemble
these messages again into one. Luckily the OTR message format is
(mostly) specific enough so that it works here.

One could implement some kind of indication that splitting has taken
place in bitlbee (and indeed I had some discussion about that with a
bitlbee developer initially) but that would also require modification of
the IRC client (which is probably why the devs wouldn't be very inclined
to implement it).

> Most of the time, the clients just do nothing, and display the
> fragmented messages to the user, which is close enough for plaintext,
> I suppose.

Indeed. Since there is no client that has been written specifically for
bitlbee.

Uli