[Standards] OTR

Dave Cridland dave at cridland.net
Fri Dec 19 21:16:30 UTC 2014


On 19 December 2014 at 20:31, Mathieu Pasquet <mathieui at mathieui.net> wrote:
>
> On Fri, Dec 19, 2014 at 02:51:02PM -0500, Sam Whited wrote:
> >
> >
> > 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.
> >
>

Also, minor point, I didn't think it was possible to do that in a secure
manner with OTR as-is. I think the library would force you to sacrifice the
ephemeral integrity. But I may very easily be wrong.


> > 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
>
> Once the work is started, it might be useful to eventually move (or
> share) the discussions to otr-dev [1] in order to have relevant feedback.
>
>
I'd assume that any future OTR protocol would be OTR encoding XML, instead
of just encoding plain text.

But you know what? That's the easy bit - the hard bit is all the subtle
bits that aren't documented. How it plays with resources, what the security
flaws are, and so on.

To get this what we need is an OTR XEP that describe what people do today.


> P.S.: I would love to have a standardized OTR where I don't have to
>       guess if the message is an HTML4 mess or plain text, something
>       the original OTR spec does not provide.
>
>
> [1]: https://lists.cypherpunks.ca/mailman/listinfo/otr-dev
>
> --
> mathieui (poezio developer)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20141219/8aa03b99/attachment.html>


More information about the Standards mailing list