Jonathan Schleifer wrote:
Dirk Meyer <[EMAIL PROTECTED]> wrote:Yes. If we only have IBB it will be Base64. Jingle will try to use something else but it may not be possible. I see no way around this problem, not matter what encryption we use. ESessions also use Base64, with Jingle-Streams we have at least a chance not to.Yeah, but we don't have a stream that is base64 encoded in a stream. Anyway, what if the server administrator has banned IBB and I'm behinda NAT? Then I'm pretty much boned.
Not necessarily. There's still SOCKS5 Bytestreams through a proxy, or ICE-TCP. Or you could switch to a different server. If a server admin does something that prevents e2e encryption and their users care about this feature, the users will complain. And even if IBB is blocked we could define yet another even simpler in-band method (even "bits of binary" as defined in XEP-0231). But of course server admins could block that, too. And nothing stops a server admin from blocking ESessions, either!
And I *DON'T* want IBB on my serverfor Jingle, I never want a video or file transfered in-band!
Is "I" the server admin or the client user?I don't see any reason would anyone would ever use IBB for video anyway, but is MTI for file transfer in XEP-0234 as a last resort.
So when I disable IBB Jingle, I also disable encryption. This gives an all or nothing situation, which sucks.
In your client you don't disable IBB for everything, you disable it for video and file transfer but not e2e streams.
I suggest to not use IBB, but have something like: <message to='foo' type='chat'> <body>This message is encrypted. If you see this text, something went wrong</body> <encryped xmlns='to_be_decided_on'>base64encoded data</encrypted> </message>
That's easy for a server admin to block, too.
That way, we can catch errors like a message was sent to the wrong resource, which doesn't support encryption etc.
Well, we could do that in IBB, too:
<message
from='[EMAIL PROTECTED]/orchard'
to='[EMAIL PROTECTED]/balcony'
id='msg1'>
<body>
This message is encrypted. If you see this text,
something went wrong
</body>
<data xmlns='http://jabber.org/protocol/ibb' sid='mySID' seq='0'>
qANQR1DBwU4DX7jmYZnncmUQB/9KuKBddzQH+tZ1ZywKK0yHKnq57kWq+RFtQdCJ
WpdWpR0uQsuJe7+vh3NWn59/gTc5MDlX8dS9p0ovStmNcyLhxVgmqS8ZKhsblVeu
IpQ0JgavABqibJolc3BKrVtVV1igKiX/N7Pi8RtY1K18toaMDhdEfhBRzO/XB0+P
AQhYlRjNacGcslkhXqNjK5Va4tuOAPy2n1Q8UUrHbUd0g+xJ9Bm0G0LZXyvCWyKH
kuNEHFQiLuCY6Iv0myq6iX6tjuHehZlFSh80b5BVV9tNLwNR5Eqz1klxMhoghJOA
</data>
</message>
There's nothing special about ESessions in this regard.
We already had problems like this when we implemented ESessions in Gajim and thus we act a little different than the standard.
Non-standardized ESessions?! I thought it was a stable technology! ;-) /psa
smime.p7s
Description: S/MIME Cryptographic Signature
