[Standards] OTR

Sam Whited 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)
- 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20141229/b60e90bb/attachment.sig>


More information about the Standards mailing list