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) - authentication - deniability - 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 provide deniability. 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 IMO.. —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com
signature.asc
Description: OpenPGP digital signature
