[OTR-dev] Re: Pidgin plugin sends and parses HTML

[Scott Ellis]

> Scott> The other serious problem in my mind is the need for a 'i'm going
> Scott> offline now' message
>
> It's not mandatory.  It didn't exist in the first version of the
> protocol.  It's just a hint to the other side that you've gone away, and
> they're free to deallocate a few resources (and forget the remaining one
> or two keys).


In previous discussions about this (too long ago for me to remember who was
involved, sorry), I commented that I'd tried to resolve the issue by
watching user status. It was mentioned that this can be exploited in an
attack if the user status can be spoofed, allowing sessions to be
continuously reset, at least chewing resources and possibly reducing the
level of security. I don't see any better options though in clients where an
'end of session' message isn't possible. Another problem with this method is
that clients who do not end sessions due to an offline status expect to be
able to continue the session with 'offline' contacts, causing at least
renegotiation but usually requiring a whole new session. And that's not even
considering offline messages and invisible users.

I'm confused by some of your terminology (I am no cryptographer): "you have
to convert between whatever you use natively and this choice before
encrypting / after decrypting" - don't you mean after encrypting/before
decrypting? You say 'plaintext of an OTR message' - which i would assume to
be the decrypted version, and then talk about the 'plaintext byes in an OTR
packet' - which I would assume to be the encrypted bytes...or are you
talking about the parts of the OTR packet that are not the encrypted
message? Nevertheless I think I understand most of what you meant. Below I'm
using 'plaintext' to mean 'decoded/unencrypted'.

With the encoding stuff, I think you are skirting the major point: for a lot
of clients (maybe even most of them) it would be more convenient if the OTR
plaintext followed the rules of the transport protocol - i.e. does not
contain HTML when using a protocol for transport that does not allow HTML in
messages. We're not just talking about ending up with HTML in the plaintext
part of jabber stanzas - we're talking about getting HTML tags in decoded
AIM messages, and other protocols that don't allow HTML at all. Jabber is
atypical and shouldn't be the protocol you use when thinking about this
stuff, imo. Also, it usually does not make sense to talk about what a
'jabber(/icq/gg/etc) client' would do (as opposed to what some other client
might do) - in a plugin-based multi-protocol messenger, you are not going to
have each protocol plugin including code for making calls to OTR - the
architecture needs to allow for encryption plugins to get their hands on
messages at the appropriate times, via callbacks or whatever. I haven't seen
a callback mechanism that would allow for the tight coupling you've
described. Protocols and encryption plugins need to be treated uniformly -
this makes encryption plugins fundamentally different from protocol plugins.
It is unusual for an encryption library to claim protocol status, and I
think it just causes problems..

I think this is why the issue of encoding has not come up. People just
expect to get out whatever they put in. There should be no need to pass in
to OTR any content-type information. The plaintext bytes should be
interpreted by the protocol as any other bunch of plaintext bytes are
interpreted - the encryption should be transparent to the protocol.

For clients that don't natively handle HTML in the interface, it creates a
lot of complications if suddenly you have HTML in messages over protocols
that would normally handle that themselves. With overly simple (niave?)
callback mechanisms, the message is decoded after the protocol has received
it but then continues on it's way to the UI without the usual processing
that the protocol plugin would do to plaintext. At a minimum that means the
decoded messages have to be passed back through any HTML stipping or
translation code, and unfortunately that code is usually packaged within the
protocol plugin and not exposed via an API. Extending this (and admittedly
getting a little bit contrived), what if the protocol allows for embedded
commands or configuration or 'customised smileys' or other similar things?
The protocol needs to get the message off the network, decrypt it, and then
get the decrypted message back to handle as it would any other. Trying to
define OTR as a protocol means losing all of this protocol-specific
functionality (which, in the case of configuration, may be essential to
workings of the protocol) and potentially being forced to include copies of
existing code.

I don't think it makes much sense to talk about putting encoded HTML in the
HTML part of a jabber message - I don't think you'll ever get agreement on
the technicalities - i.e. whether it is still HTML when encoded. Imo, a
solution that works for jabber is unlikely to work generically. I think the
appropriate way to handle jabber would be to take both elements, perhaps
even the whole iq stanza, and embed the encrypted version in a message as if
it were text/plain data. That would prevent the kinds of attacks you
mention, and perhaps make it possible to treat jabber more like other
protocols. As it is a special case I think it would be justified if jabber
clients and plugins did make their own specific calls to the OTR library, if
that turned out to be necessary.

I've never had to worry about the encoding used for encrypted OTR messages
either - there ought to be encoding information passed from the protocol to
OTR during decryption and encryption. E.g. the message being sent comes in
to the protocol, is formatted for sending and passed to OTR along with
information about it's encoding. It will be converted to UTF8, encoded by
OTR, and the encrypted version converted back to the encoding used by the
protocol.

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20080514/6f614c1f/attachment.html>