[Standards] OTR

Sam Whited sam at samwhited.com
Fri Dec 19 19:51:02 UTC 2014



On 12/17/2014 11:46 AM, Winfried Tilanus wrote:
> In response to my comment that it left a lot of information
> unencrypted he suggested to start a second OTR protocol in XMPP, one
> that does proper service discovery and properly encrypts everything
> of the stanzas that should be encrypted. Optionally embedding the
> plain version within it when you need to transverse to an other
> protocol.

Agreed (that there should be an XMPP flavor of OTR); I'm not so sure
that embedding the plain version within the XMPP discovered version
would be helpful, this sounds like an edge case that won't often happen
in 'real life' to me.

One of the major problems with XMPP in general as I see it, is that
extensions try to cover too many little edge cases that aren't ever
likely to arrise and be a "one size fits all" solution. This leads to
them being difficult to implement properly, which leads to
incompatibilities and fragmentation among clients.

Keeping things simple, and straightforward is the way to go IMO,
especially in a security sensitive environment.

That being said, embedding the normal OTR exchange isn't that
complicatedm it just seems unnecessary to me; sorry, got a little
sidetracked there.

> Well... I think the first step should be documenting the most common
> case, OTR'ing the content of a message in the OTR way....

Also agreed. Let's pump out a basic informational XEP that describes the
state of OTR today, and in the mean time we can be discussing how we
want to expand it in future.

—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/20141219/578e871d/attachment.sig>


More information about the Standards mailing list