sam at samwhited.com
Mon Dec 29 17:36:35 UTC 2014
I've got a few sections written for the descriptive document; may merge
them later after I figure out how to generate something readable from
these aweful XML documents... (*grumble, grumble*)
On 12/23/2014 11:03 AM, Bartosz Małkowski wrote:
> I think we should determine goals we want to achieve and more or less
> features of this protocol. As short list.
Whatever we do, the main thing will be to be careful to keep all the
properties of regular OTR. That is:
- encryption (obvoiusly)
- perfect forward secrecy.
We could possibly even add the ability to deny that OTR.was being used
at all (no really, I was just sending random data in a bunch of message
stanzas... what's OTR?). I don't think this is necessary and will just
complicate things though.
The main problem I see there would be deniability; a lot of things I see
people suggest would potentially ruin the ability of the protocol to
The main design decision (in my mind), is whether to "integrate" our
protocol into the normal XMPP stream, or use it for full stream
encryption (restart the stream inside of a special "OTR" stream).
Personally, I'm for the second option.
Finally, we should design to prevent side effects when used in
conjunction with stream resumption, message carbons (eg. all OTR
messages must be marked as "private" and "no-copy", which should be in
our best practices document as well, incidentally), and possibly others
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the Standards