<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Scott> The other serious problem in my mind is the need for a 'i'm going<br>

Scott> offline now' message<br>
<br>
It's not mandatory.  It didn't exist in the first version of the<br>
protocol.  It's just a hint to the other side that you've gone away, and<br>
they're free to deallocate a few resources (and forget the remaining one<br>
or two keys). </blockquote><div><br>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.<br>
<br>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'.<br>
<br>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..<br>
<br>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.<br>
<br>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.<br>
<br>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.<br>
<br>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.<br>
<br>Scott<br></div></div>