Re: [Standards] OTR

[Carlo v. Loesch]

On Tue, Feb 03, 2015 at 02:22:33PM +0100, Ralph Meijer wrote:
> I think everyone in our community knows that XMPP, as currently
> designed, has no simple mechanism to obscure who's communicating with
> whom. Going into more detail, federation as in e-mail or XMPP has this
> problem in both extremes: if everyone is running their own server
> (instead of a cloud service that could be compromised by a government
> agency), the number of people associated with such a server is likely to
> be low, making it easier to find out who's behind it.

Thanks for the ack, Ralph.

> However, that is just one threat model, one that someone may or may not
> find important enough to fix. Efforts to address other threat models
> (like secrecy of messages themselves) are not suddenly worthless if you
> can't hide who's communicating. Also, documenting current practise still
> seems a great idea, to me.

The problem here is that far too many people are investing time in the
old communications model, be it applying crypto to SMTP or XMPP. And
yet should one day, against the odds of disinterest or distraction, an
actually functional distributed communications network arise, serving
a better job at both messaging and social networking than even the cloud
systems, how much does it matter, that SMTP or XMPP are safe from the
perspective of some lesser threat models? It reminds me a bit of all the
effort that went into digital fax technology. With my ISDN router came
the ability to send fax directly from the word processor and to receive
fax in text form thanks to automatic OCR. Yet, all the world switched to
e-mail anyway. Why should they stick to a fax system even if it was
fully integrated into the computing experience?

Also, what lesser threat models can make sense? The exercise of democracy
depends on constitutional freedoms like Secrecy of Correspondence and
Freedom of Association (= metadata protection). With technology that has
within only twenty years turned all democratic populations on Earth into
fully surveillable and predictable populace, can there be any more
important threat model? What's the use for a Syrian dissident that Google
is on her side if in ten years later all her activity data can be handed 
over to the then possibly pro-Western government of Syria?

I know these people are better served with something now than too late,
but that's what they already have. The next thing they need is something 
that defends metadata - the foundation for forming a political opposition,
the essential capacity of renewal of democracy. If we leave metadata up
for grabs, we are co-responsible for a slippery slope towards global
dismantlement of democracies. It doesn't take any evil conspiracies -
it's the technology enabling and leading the way to hell.

That's why I suggest you should not spend further years trying to 
get at so-called low-hanging fruit which each time ends up not hanging 
low at all (multi-end OTR is such a case) while there are new paradigms
of Internet technology out there, waiting to be fleshed out and given
a chance to protect humanity from itself. That stuff needs people
like you.


-- 
  E-mail is public! Talk to me in private using Tor.
  torify telnet loupsycedyglgamf.onion  DON'T SEND ME
  irc://loupsycedyglgamf.onion:67/lynX  PRIVATE EMAIL
 http://loupsycedyglgamf.onion/LynX/OR FACEBOOGLE

Re: [Standards] OTR

[Ralph Meijer]

On 2015-02-03 12:52, Carlo v. Loesch wrote:
> If you're interested in looking beyond the XMPP bowl there has been
> very similar discussion in the post-XMPP "messaging" list:
> 
> https://moderncrypto.org/mail-archive/messaging/2015/001309.html
> "Multiple devices and key synchronization"
> 
> https://moderncrypto.org/mail-archive/messaging/2015/001354.html
> "Key rotation"
> 
> On Tue, Feb 03, 2015 at 11:07:40AM +0100, Winfried Tilanus wrote:
>> https://github.com/winfried/XMPP-OTR
> 
> I think the XMPP/OTR/Tor combination is what people are using *today*
> because you have to start somewhere and the other options (TorChat or
> Retroshare via Tor) aren't as mature.
> 
> Yet I think the XMPP community should REALLY REALLY acknowledge
> that the metadata issue IS more important than the forward secrecy
> aspect and that applying a bit of Tor on the way to the server
> is NOT a sufficient solution.

Hi Carlo,

I think everyone in our community knows that XMPP, as currently
designed, has no simple mechanism to obscure who's communicating with
whom. Going into more detail, federation as in e-mail or XMPP has this
problem in both extremes: if everyone is running their own server
(instead of a cloud service that could be compromised by a government
agency), the number of people associated with such a server is likely to
be low, making it easier to find out who's behind it.

However, that is just one threat model, one that someone may or may not
find important enough to fix. Efforts to address other threat models
(like secrecy of messages themselves) are not suddenly worthless if you
can't hide who's communicating. Also, documenting current practise still
seems a great idea, to me.

-- 
ralphm

Re: [Standards] OTR

[Daniele Ricci]

Of course, I was just talking about a deterministic way of describing the
encrypted data - and to save bandwidth.

Anyway the point of metadata leakage is valid. We (as in XMPP) do what we
can and we encrypt what we can. Anonymity was never the scope of XMPP.

Daniele
On 3 Feb 2015 12:59, "Bartosz Małkowski"  wrote:

>
> > Wiadomość napisana przez Daniele Ricci  w
> dniu 3 lut 2015, o godz. 12:20:
> >
> > The only problem here is how to recognise the encrypted data? Is it a
> > text body or a stanza? Maybe we can use a "type" attribute to ,
> > revealing more metadata? Or maybe we could add a header to the
> > encrypted data:
>
> I don’t understand.
>
> If client receives …
> then it will decrypt data and expect that result of decryption is stanza
> (or maybe other element allowed in XMPP Stream), then client will process
> received and decrypted element like any other received elements.
>
> Look at https://tools.ietf.org/html/draft-miller-xmpp-e2e-02 (4.3.
> Example - Securing a Message). The same idea.
>
> --
> Bartosz Małkowski
> Tigase Polska
> xmpp:bmal...@malkowscy.net
>
>

Re: [Standards] OTR

[Bartosz Małkowski]

> Wiadomość napisana przez Daniele Ricci  w dniu 3 
> lut 2015, o godz. 12:20:
> 
> The only problem here is how to recognise the encrypted data? Is it a
> text body or a stanza? Maybe we can use a "type" attribute to ,
> revealing more metadata? Or maybe we could add a header to the
> encrypted data:

I don’t understand.

If client receives …
then it will decrypt data and expect that result of decryption is stanza (or 
maybe other element allowed in XMPP Stream), then client will process received 
and decrypted element like any other received elements.

Look at https://tools.ietf.org/html/draft-miller-xmpp-e2e-02 (4.3.  Example - 
Securing a Message). The same idea.

--
Bartosz Małkowski
Tigase Polska
xmpp:bmal...@malkowscy.net



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] OTR

[Carlo v. Loesch]

If you're interested in looking beyond the XMPP bowl there has been
very similar discussion in the post-XMPP "messaging" list:

https://moderncrypto.org/mail-archive/messaging/2015/001309.html
"Multiple devices and key synchronization"

https://moderncrypto.org/mail-archive/messaging/2015/001354.html
"Key rotation"

On Tue, Feb 03, 2015 at 11:07:40AM +0100, Winfried Tilanus wrote:
> https://github.com/winfried/XMPP-OTR

I think the XMPP/OTR/Tor combination is what people are using *today*
because you have to start somewhere and the other options (TorChat or
Retroshare via Tor) aren't as mature.

Yet I think the XMPP community should REALLY REALLY acknowledge
that the metadata issue IS more important than the forward secrecy
aspect and that applying a bit of Tor on the way to the server
is NOT a sufficient solution.

As George Danezis expressed it in his 31c3 presentation, social
graphs tent to be isomorphic. No matter how well you pseudonymize
your identity via Tor, the people you add to your roster are
going to be similar to the ones you already added to other social
graphs. The 2009 paper "de-anonymizing social networks" shows how
an attacker can correlate social graphs.

So if a five eyes state agency wants to know everyone's identities
on jabber.org or jabber.ccc.de, it either needs to obtain access 
to the server data base, or apply plenty of traffic shaping over 
a period of time, to extract that graph - then compare it to 
existing intelligence such as the Facebook, Twiter or e-mail
social network graphs.

In other words, no matter how much OTR and Tor we throw at it,
the fact that XMPP uses federated servers will always put our
metadata at risk. Federation has also failed us ideologically:
Each time a federated protocol becomes popular, cloud offerings 
turn out to be the most efficient, scalable and easy to adopt
for the masses. Thus federated protocols such as SMTP and XMPP
have been a slippery slope leading into centralized cloud dependency -
legitimizing platforms such as Gmail and G-Talk. Even Facebook Chat.

If you want to do the world some good, help us work on a distributed,
end-to-end encrypted and forward secret technology that builds upon
agnostic anonymizing relay nodes rather than federated servers. An
architecture that keeps the social graph completely on the devices
of the users rather than replicating it into the network infrastructure.

You may find this thread interesting. It discusses the possibilities
of implementing a one-to-many messaging system into the backbone of Tor:

https://lists.torproject.org/pipermail/tor-talk/2014-December/036251.html
"Cryptographic social networking project"

Concluding, please use XMPP for things it is appropriate for... don't
try to do privacy with it. It's a battle we can't win.


-- 
  E-mail is public! Talk to me in private using Tor.
  torify telnet loupsycedyglgamf.onion  DON'T SEND ME
  irc://loupsycedyglgamf.onion:67/lynX  PRIVATE EMAIL
 http://loupsycedyglgamf.onion/LynX/OR FACEBOOGLE

Re: [Standards] OTR

[Goffi]

Some clients do weird stuff like encoding XHTML-IM (which is probably 
not a good idea at all). Also a XEP should give some advices on what to 
allow, saying that history should be disabled by default, this kind of 
things.


Also there is an OTR space-based discovery system which should be 
useless in XMPP (except if you use OTR with gateway/legacy networks). 
Maybe a XEP should explain what to do, if we need to announce there 
somewhere with XMPP discovery, etc.


On 03/02/2015 10:37, Florian Schmaus wrote:

Isn't "documenting the current OTR usage in XMPP" simply


  
 … put OTR stuff here …
  


where "OTR stuff" is defined at
https://otr.cypherpunks.ca/Protocol-v2-3.1.0.html (I think most
implementations use OTR v2) and
https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html

So OTR is IM protocol-agnostic. You can see how OTR tries to negotiate
using whitespaces at the end of String within the  element at
https://github.com/python-otr/gajim-otr/issues/9#issue-40676864

I'm also not sure if, not only because it's IM protocol-agnostic, OTR
would be a good fit for IoT. Some research in this direction would sure
be interesting.

- Florian

Re: [Standards] OTR

[Kim Alvefur]

On 2015-02-03 11:07, Winfried Tilanus wrote:
> On 03-02-15 11:03, Ralph Meijer wrote:
>> Sure it will be short. However, some notes on limitations and security
>> considerations would also need to be added. If only to make it easier to
>> compare against other e2e proposals. If you want to make a start with a
>> XEP, that's appreciated.
> 
> https://github.com/winfried/XMPP-OTR
> 
> If you give me your github name, I will give you write access ;-)

I have an early draft I started on for "Current OTR Usage in XMPP" but
I've been busy with other things.  It has some of the issues we have
with it written down, which needs to be word-smithed to something more
formal.

Might be useful as a starting point.

--
Kim "Zash" Alvefur
Title: XEP-: Current OTR Usage in XMPP



  
  
XEP-: Current OTR Usage in XMPP

  

  Abstract:

This document outlines the current usage of OTR for encrypted messaging.
  
  

  Author:

Kim Alvefur
  
  

  Copyright:

© 1999 - 2014 XMPP Standards Foundation. SEE LEGAL NOTICES.
  
  

  Status:

ProtoXEP
  
  

  Type:

Historical
  
  

  Version:

0.1
  
  

  Last Updated:

2013-12-20
  


WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document is not yet an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at  and announced on the  mailing list.

Table of Contents

  1.  Introduction2.  Negotiation3.  Encrypting4.  Security Considerations5.  Other Known Issues6.  IANA Considerations7.  XMPP Registrar Considerations
  AppendicesA: Document InformationB: Author InformationC: Legal NoticesD: Relation to XMPPE: Discussion VenueF: Requirements ConformanceG: NotesH: Revision History


1.
   Introduction

The Jabber community has long acknowledged the need for privacy and security features in a well-rounded instant messaging system.
Unfortunately, finding a consensus solution to the problem of end-to-end encryption is still not really solved.
Lots of people are using Off-the-Record Communication  [1].
This specification documents OTR as it is used in XMPP today.
This document is not intended to present a standard, because more complete solutions are being investigated.
  
2.
   Negotiation
Negotiation and encrypted content goes over normal  stanzas in the  child.
Example 1. Requests to start OTR

  

  ?OTRv23? If you can read this, you don't support OTR.



3.
   Encrypting
Example 2. An encrypted message stanza

  

  ?OTR:AAEDTmdnbnB4IG5nIHFuamEhCg==.



It is considered polite to include an unencrypted message , but this is not possible in OTR due to the use of the  for carrying the encrypted payload.
4.
   Security Considerations
The method described herein has the following security issues:

  No encryption of complete stanzas
  Non-body payloads are not secured
  Anything else?

5.
   Other Known Issues
In addition to the security considerations listed above, there are several other known issues with this method:

  Gets messy with multiple resources or Message Carbons (XEP-0280)  [2].
  Not integrated with XMPP.
  Does not work with Offline messages or archives. (Some may consider this a good thing)

6.
   IANA Considerations
This document requires no interaction with the Internet Assigned Numbers Authority (IANA)  [3].
7.
   XMPP Registrar Considerations
This document requires no interaction with the XMPP Registrar.


Appendices


Appendix A: Document Information

Series: XEP
Number: 
Publisher: XMPP Standards Foundation
Status: 
ProtoXEP
Type:
Historical
Version: 0.1
Last Updated: 2013-12-20
Approving Body: XMPP CouncilDependencies: XMPP Core, OTR spec?
Supersedes: None
Superseded By: None
Short Name: otr
This document in other formats: 
XML 
PDF


Appendix B: Author Information

  Kim Alvefur
  
Email:
z...@zash.se
JabberID: 
z...@zash.se



Appendix C: Legal Notices
CopyrightThis XMPP Extension Protocol is copyright © 1999 - 2014 by the XMPP Standards Foundation (XSF).PermissionsPermission is hereby granted, free of charge, to any person obtain

Re: [Standards] OTR

[Daniele Ricci]

Hello everybody,
referring to commit:
https://github.com/winfried/XMPP-OTR/commit/76a5cf06a3728e042740c0e30ba535e55b2613a8

I know it's still work in progress, but I want to start from there to
say my two cents.
I think encrypting the whole stanza can be avoided in some cases.
Also, the only stanza type that has sense to be encrypted with OTR is
. Therefore, I'd distinguish between two specific cases:

* encryption of message body: just include the encrypted message body
in the  element as a child of 
* encryption of whole stanza (for other purposes or for complex
messages): encrypt the whole stanza and encapsulate the OTR content in
an  element as a child of 

The only problem here is how to recognise the encrypted data? Is it a
text body or a stanza? Maybe we can use a "type" attribute to ,
revealing more metadata? Or maybe we could add a header to the
encrypted data:

-8<---
Content-type: text/plain

message body
-8<---

-8<---
Content-type: application/xmpp+xml


 


What do you think?


On Tue, Feb 3, 2015 at 11:07 AM, Winfried Tilanus  wrote:
> On 03-02-15 11:03, Ralph Meijer wrote:
>> Sure it will be short. However, some notes on limitations and security
>> considerations would also need to be added. If only to make it easier to
>> compare against other e2e proposals. If you want to make a start with a
>> XEP, that's appreciated.
>
> https://github.com/winfried/XMPP-OTR
>
> If you give me your github name, I will give you write access ;-)
>
> Winfried



-- 
Daniele

Re: [Standards] OTR

[Winfried Tilanus]

On 03-02-15 11:03, Ralph Meijer wrote:
> Sure it will be short. However, some notes on limitations and security
> considerations would also need to be added. If only to make it easier to
> compare against other e2e proposals. If you want to make a start with a
> XEP, that's appreciated.

https://github.com/winfried/XMPP-OTR

If you give me your github name, I will give you write access ;-)

Winfried

Re: [Standards] OTR

[Ralph Meijer]

On February 3, 2015 10:37:14 AM WAT, Florian Schmaus  wrote:
>On 03.02.2015 10:04, Dave Cridland wrote:
>> On 2 Feb 2015 18:49, "Peter Saint-Andre - &yet" > > wrote:
>>> On 2/2/15 5:22 AM, Hund, Johannes wrote:
 Since it was undisclosed that even the NSA seems to have problems
 breaking into OTR [1], it gained a lot of attention it seems and
>thus
 does a good deal in supporting XMPP as a choice for applications
>with
 high requirements in privacy and security as its often the case for
 IoT applications.
>>>
>>>
>>> OTR secures only the character data of the XMPP  element
>within
>> message stanzas. That's appropriate for IM but doesn't really help
>with
>> things like IoT (which often use extended namespaces).
>>>
>> 
>> Exactly, and this is the kind of thing I was hoping that documenting
>the
>> current OTR usage in XMPP would show clearly.
>
>Isn't "documenting the current OTR usage in XMPP" simply
>
>
> 
>… put OTR stuff here …
> 
>
>
>where "OTR stuff" is defined at
>https://otr.cypherpunks.ca/Protocol-v2-3.1.0.html (I think most
>implementations use OTR v2) and
>https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html
>
>So OTR is IM protocol-agnostic. You can see how OTR tries to negotiate
>using whitespaces at the end of String within the  element at
>https://github.com/python-otr/gajim-otr/issues/9#issue-40676864
>
>I'm also not sure if, not only because it's IM protocol-agnostic, OTR
>would be a good fit for IoT. Some research in this direction would sure
>be interesting.
>
>- Florian

Sure it will be short. However, some notes on limitations and security 
considerations would also need to be added. If only to make it easier to 
compare against other e2e proposals. If you want to make a start with a XEP, 
that's appreciated.
-- 
ralphm

Re: [Standards] OTR

[Dave Cridland]

On 3 Feb 2015 09:37, "Florian Schmaus"  wrote:
>
> On 03.02.2015 10:04, Dave Cridland wrote:
> > On 2 Feb 2015 18:49, "Peter Saint-Andre - &yet"  > > wrote:
> >> On 2/2/15 5:22 AM, Hund, Johannes wrote:
> >>> Since it was undisclosed that even the NSA seems to have problems
> >>> breaking into OTR [1], it gained a lot of attention it seems and thus
> >>> does a good deal in supporting XMPP as a choice for applications with
> >>> high requirements in privacy and security as its often the case for
> >>> IoT applications.
> >>
> >>
> >> OTR secures only the character data of the XMPP  element within
> > message stanzas. That's appropriate for IM but doesn't really help with
> > things like IoT (which often use extended namespaces).
> >>
> >
> > Exactly, and this is the kind of thing I was hoping that documenting the
> > current OTR usage in XMPP would show clearly.
>
> Isn't "documenting the current OTR usage in XMPP" simply
>
> 
>  
> … put OTR stuff here …
>  
> 
>

That's certainly the core of it, though the devil is usually in the
details. I suspect there's all sorts of weird stuff with multiple
resources, for instance, and html, and...

> where "OTR stuff" is defined at
> https://otr.cypherpunks.ca/Protocol-v2-3.1.0.html (I think most
> implementations use OTR v2) and
> https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html
>
> So OTR is IM protocol-agnostic. You can see how OTR tries to negotiate
> using whitespaces at the end of String within the  element at
> https://github.com/python-otr/gajim-otr/issues/9#issue-40676864
>
> I'm also not sure if, not only because it's IM protocol-agnostic, OTR
> would be a good fit for IoT. Some research in this direction would sure
> be interesting.
>
> - Florian
>

It'd be nice to have a document which held our consensus view on what OTR
in XMPP protects against, and what it fails to protect against, and how one
implements it. Currently it's one of those things that "everybody knows",
and I'm willing to admit that I am not "everybody".

Dave.

Re: [Standards] OTR

[Florian Schmaus]

On 03.02.2015 10:04, Dave Cridland wrote:
> On 2 Feb 2015 18:49, "Peter Saint-Andre - &yet"  > wrote:
>> On 2/2/15 5:22 AM, Hund, Johannes wrote:
>>> Since it was undisclosed that even the NSA seems to have problems
>>> breaking into OTR [1], it gained a lot of attention it seems and thus
>>> does a good deal in supporting XMPP as a choice for applications with
>>> high requirements in privacy and security as its often the case for
>>> IoT applications.
>>
>>
>> OTR secures only the character data of the XMPP  element within
> message stanzas. That's appropriate for IM but doesn't really help with
> things like IoT (which often use extended namespaces).
>>
> 
> Exactly, and this is the kind of thing I was hoping that documenting the
> current OTR usage in XMPP would show clearly.

Isn't "documenting the current OTR usage in XMPP" simply


 
… put OTR stuff here …
 


where "OTR stuff" is defined at
https://otr.cypherpunks.ca/Protocol-v2-3.1.0.html (I think most
implementations use OTR v2) and
https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html

So OTR is IM protocol-agnostic. You can see how OTR tries to negotiate
using whitespaces at the end of String within the  element at
https://github.com/python-otr/gajim-otr/issues/9#issue-40676864

I'm also not sure if, not only because it's IM protocol-agnostic, OTR
would be a good fit for IoT. Some research in this direction would sure
be interesting.

- Florian



signature.asc
Description: OpenPGP digital signature

Re: [Standards] OTR

[Dave Cridland]

On 2 Feb 2015 18:49, "Peter Saint-Andre - &yet"  wrote:
>
> On 2/2/15 5:22 AM, Hund, Johannes wrote:
>>
>> Hi,
>>
>> while I cannot help with it, I would be very thankful and greatly
>> welcome a document on what is and how to use OTR.
>>
>> Since it was undisclosed that even the NSA seems to have problems
>> breaking into OTR [1], it gained a lot of attention it seems and thus
>> does a good deal in supporting XMPP as a choice for applications with
>> high requirements in privacy and security as its often the case for
>> IoT applications.
>
>
> OTR secures only the character data of the XMPP  element within
message stanzas. That's appropriate for IM but doesn't really help with
things like IoT (which often use extended namespaces).
>

Exactly, and this is the kind of thing I was hoping that documenting the
current OTR usage in XMPP would show clearly.

> Peter
>
> --
> Peter Saint-Andre
> https://andyet.com/

Re: [Standards] OTR

[Bartosz Małkowski]

> Wiadomość napisana przez Peter Saint-Andre - &yet  w dniu 2 
> lut 2015, o godz. 19:47:
> 
> OTR secures only the character data of the XMPP  element within 
> message stanzas. That's appropriate for IM but doesn't really help with 
> things like IoT (which often use extended namespaces).

Thats why we are trying (again!) to prepare e2e encryption specification (one 
more!). ;-)


What you decided during Summit? I hope you have talks about e2e encryption.
I just changed architecture of my XMPP library to allow set up „virtual XMPP 
Streams” between two entities, but I can’t use it :-(

--
Bartosz Małkowski
Tigase Polska
xmpp:bmal...@malkowscy.net



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] OTR

On 2/2/15 5:22 AM, Hund, Johannes wrote:

Hi,

while I cannot help with it, I would be very thankful and greatly
welcome a document on what is and how to use OTR.

Since it was undisclosed that even the NSA seems to have problems
breaking into OTR [1], it gained a lot of attention it seems and thus
does a good deal in supporting XMPP as a choice for applications with
high requirements in privacy and security as its often the case for
IoT applications.


OTR secures only the character data of the XMPP  element within 
message stanzas. That's appropriate for IM but doesn't really help with 
things like IoT (which often use extended namespaces).


Peter

--
Peter Saint-Andre
https://andyet.com/

Re: [Standards] OTR

[Steffen Larsen]

Hi, 

Yes a good idea. Maybe we could try to update this one: 
http://wiki.xmpp.org/web/OTR 

/Steffen

> On 02 Feb 2015, at 13:22, Hund, Johannes  wrote:
> 
> Hi,
> 
> while I cannot help with it, I would be very thankful and greatly welcome a 
> document on what is and how to use OTR.
> 
> Since it was undisclosed that even the NSA seems to have problems breaking 
> into OTR [1], it gained a lot of attention it seems and thus does a good deal 
> in supporting XMPP as a choice for applications with high requirements in 
> privacy and security as its often the case for IoT applications.
> 
> [1]: 
> http://www.spiegel.de/international/germany/inside-the-nsa-s-war-on-internet-security-a-1010361.html
> 
> Best Regards,
> Johannes
> 
> Von: Standards [mailto:standards-boun...@xmpp.org] Im Auftrag von Dave 
> Cridland
> Gesendet: Freitag, 7. November 2014 10:56
> An: XMPP Standards
> Betreff: [Standards] OTR
> 
> In an internal discussion at Surevine, OTR was mentioned, and it was moaned 
> that OTR usage in XMPP isn't actually documented anywhere we know of.
> 
> Is anyone willing to help work on a XEP to explain how to run OTR over XMPP, 
> and catalogue limitations etc?
> 
> Dave.

Re: [Standards] OTR

[Hund, Johannes]

Hi,

while I cannot help with it, I would be very thankful and greatly welcome a 
document on what is and how to use OTR.

Since it was undisclosed that even the NSA seems to have problems breaking into 
OTR [1], it gained a lot of attention it seems and thus does a good deal in 
supporting XMPP as a choice for applications with high requirements in privacy 
and security as its often the case for IoT applications.

[1]: 
http://www.spiegel.de/international/germany/inside-the-nsa-s-war-on-internet-security-a-1010361.html

Best Regards,
Johannes

Von: Standards [mailto:standards-boun...@xmpp.org] Im Auftrag von Dave Cridland
Gesendet: Freitag, 7. November 2014 10:56
An: XMPP Standards
Betreff: [Standards] OTR

In an internal discussion at Surevine, OTR was mentioned, and it was moaned 
that OTR usage in XMPP isn't actually documented anywhere we know of.

Is anyone willing to help work on a XEP to explain how to run OTR over XMPP, 
and catalogue limitations etc?

Dave.

Re: [Standards] OTR

[Winfried Tilanus]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/26/2015 03:49 PM, Sam Whited wrote:

Hi Sam,

> P.S. I've been a bit out of the loop lately, as I've been
> travelling and interviewing for jobs, so I haven't been able to
> work on the current OTR usage XEP (I know I keep saying I'm going
> to get on that... or at least respond to my emails). Sorry about
> that.

Thanks for the update, I was wondering already.

Winfried
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJUx0oeAAoJEHZ7UH0X6Ldc+TcQALscz2IlftGft03yNw5QKK+O
iaibKrCSNMj0TCLR+ES79VDhA5H3mOIA025Ee+kVzJSMbw069SCYAT90kPrPYO6v
n/44PF+WAnV8DfHmMRvdUT4k4K63aIK4dKo8GfgRRz3QS73xDaIGFJI+M/FaC56K
DZOdnBSDsYaAjABEemtZTj5kgZ8DlxG34gm0TMCjpdcb0mOb2qMnhGmbWkL88CEG
msCgGqeNW1nW3GuOHhqfCx72ylos9Datpo7Zta5YAZAMUOCjCIGjP4yzZmsQhL5V
qLx2beAs4zVpjmTGxpsscE5vBty835V9Rey2TK2dDyuEwn9g2JPebhKV9RTPoiZq
LKywBQX1FkIifztz1rNn7SFkAP/aZWOCKrYxWY4Jv8Eapjo8LP6urLZv1ZnHCDRd
8m98vTJSwLaH/WL3MH6alAaf4XsFkub9GBkEofazCcU9EYnFOwjgrD4mjtcxDBtw
rbsvMkfDAEvGlpgSQf9VZrmiPwFiDGlSRD/rXhvzw7LRkGAmhasLehlF6KVrkFnh
64pUIVmMYYeZGfTWgzB8vZdpS/26sPV8sqYF3vEMSUFE9eVEouD7hfM003y7ZfpU
X+umVvb3AS4IlECTuXIFL5HA2RW0rnPJd2Jnj9LTmTIJt9rELuwL+BYGzAyPirSk
xnipde7ZNP9BHIIfcvaD
=VF4I
-END PGP SIGNATURE-

Re: [Standards] OTR

[Sam Whited]

On 01/26/2015 01:49 AM, Bartosz Małkowski wrote:
> https://blog.thijsalkema.de/me/blog//blog/2015/01/23/multi-end-to-multi-end-encryption/

A good read, thanks for posting.


On 01/26/2015 04:10 AM, Georg Lukas wrote:
> c) it would be great to leverage this to secure file transfers / uploads
> as well as media streams.

Since media streaming and file transfers are generally P2P, I think
there are better ways of securing them (eg. TLS). The existing message
encryption could be used to sign part of the TLS session construction if
needed so that you could verify that the person you're receiving a file
stream from is the same one you were talking with.

—Sam

P.S. I've been a bit out of the loop lately, as I've been travelling and
interviewing for jobs, so I haven't been able to work on the current OTR
usage XEP (I know I keep saying I'm going to get on that... or at least
respond to my emails). Sorry about that.

Related: If anyone from HipChat is on this list, I'll be in Austin next
week interviewing with you guys; be sure to say hi and let's grab a
coffee or something.

-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com



signature.asc
Description: OpenPGP digital signature

Re: [Standards] OTR

[Winfried Tilanus]

On 01/26/2015 09:19 AM, Steffen Larsen wrote:

> A good discussion for the summit I would say. :-)

Thijs,

Are you able to come to Brussels Thursday and/or Friday or to
participate remotely one of these days? It would be really great to have
your input in the e2e / OTR discussion at the summit.

Winfried

Re: [Standards] OTR

[Thijs Alkemade]

On 26 jan. 2015, at 10:10, Georg Lukas  wrote:

> * Bartosz Małkowski  [2015-01-26 07:58]:
>> https://blog.thijsalkema.de/me/blog//blog/2015/01/23/multi-end-to-multi-end-encryption/

Hi,

Author of the post here, nice to see it’s already being discussed.

> This is a great writeup. Having multi-device end-to-end encryption
> with offline storage will significantly improve the security and
> usability of XMPP for normal people.
> 
> I'd like to add some more points to the discussion though:
> 
> a) it is important to allow security-conscious people to actually check
> the security properties, so the list of devices/keys/fingerprints needs
> to be exposed to power users, plus additional information messages when
> the list is extended.

Agreed completely.

> b) a protocol/approach for adding devices to the list needs to be
> created, maybe deploying some kind of cross-signing between one old and
> the new device?

Good point, I haven’t covered that, but adding new devices will indeed be
more complicated than it is now.

One way this could work is that you need one of the devices that already has a
key on your account to bootstrap the new device (signing the new device's
public key with its key). If the old device has some local logs, it could push
some to the new device to still give it some backlog (re-encrypted with the
new device’s key).

But it does create a barrier for users. I know Firefox Sync did something like
that (requiring you to input some characters from the browser on one device on
the new one to add it to the sync), but apparently too many people didn’t like
it, so it was removed.

> c) it would be great to leverage this to secure file transfers / uploads
> as well as media streams.

If you just want to exchange one symmetric key, that should work fine. But
using the protocol itself for filetransfers/media streams is likely going to
give bad performance.

> d) multi-device end-to-end encryption can also elegantly solve the MUC
> security problem. Let's do it so.

I don't think this solution will scale well to a group chat with more than ~10
people. The number of devices people have will likely be limited in practice,
but the number of participants in a group chat can get quite large. I think
there are better solutions for encrypting MUCs.

Regards,
Thijs


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] OTR

[Georg Lukas]

* Bartosz Małkowski  [2015-01-26 07:58]:
> https://blog.thijsalkema.de/me/blog//blog/2015/01/23/multi-end-to-multi-end-encryption/

This is a great writeup. Having multi-device end-to-end encryption
with offline storage will significantly improve the security and
usability of XMPP for normal people.

I'd like to add some more points to the discussion though:

a) it is important to allow security-conscious people to actually check
the security properties, so the list of devices/keys/fingerprints needs
to be exposed to power users, plus additional information messages when
the list is extended.

b) a protocol/approach for adding devices to the list needs to be
created, maybe deploying some kind of cross-signing between one old and
the new device?

c) it would be great to leverage this to secure file transfers / uploads
as well as media streams.

d) multi-device end-to-end encryption can also elegantly solve the MUC
security problem. Let's do it so.


Georg
-- 
|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e h- r++ y?   ||
++ IRCnet OFTC OPN ||_||


signature.asc
Description: Digital signature

Re: [Standards] OTR

[Bartosz Małkowski]

> Wiadomość napisana przez Steffen Larsen  w dniu 26 sty 
> 2015, o godz. 09:19:
> 
> A good discussion for the summit I would say. :-)
> 

:-)

Indeed. Let decide something. I’m changing architecture of my XMPP library to 
allow easy extend it by any implementation of virtual xmpp streams :-) I will 
be able to add implementation of all e2e encryption protocols ;-)

Regards!

--
Bartosz Małkowski
Tigase Polska
xmpp:bmal...@malkowscy.net



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] OTR

[Steffen Larsen]

A good discussion for the summit I would say. :-)

/Steffen

> On 26 Jan 2015, at 07:49, Bartosz Małkowski  wrote:
> 
> https://blog.thijsalkema.de/me/blog//blog/2015/01/23/multi-end-to-multi-end-encryption/
> 
> --
> Bartosz Małkowski
> Tigase Polska
> xmpp:bmal...@malkowscy.net
> 

Re: [Standards] OTR

[Bartosz Małkowski]

https://blog.thijsalkema.de/me/blog//blog/2015/01/23/multi-end-to-multi-end-encryption/

--
Bartosz Małkowski
Tigase Polska
xmpp:bmal...@malkowscy.net



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] OTR

[Sam Whited]

On 12/29/2014 01:37 PM, Bartosz Małkowski wrote:
> 
>> Wiadomość napisana przez Sam Whited  w dniu 29 gru 2014, 
>> o godz. 18:36:
>>
>> 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.
> 
> Can you explain?

Eg. the suggestion someone made earlier about adding signing of OTR
keys. Any sort of signing should be a no (it's not part of the original
OTR protocol, and is contrary to its goals). I've seen this sort of
thing suggested a few times elsewhere.

Rereading that paragraph, I'm confused as to what I was talking about
too; possibly ignore it and just read that as "we should keep OTR's
goals in mind as we develop to make sure we don't inadvertantly leak
information and break one of those goals".

> If encrypted stream will be established, then what problems you see?
> We can’t hide fact that OTR stream is established between two
> entities.

Different kind of deniability (sorry, my message was confusing as I
mentioned both, and it may have sounded like I was talking about the
same thing). You're probably right; don't know why I even mentioned that
(the initial OTR stream setup will always show that OTR was being used,
even if OTR messages are designed in such a way that there could be
plausable deniability that OTR was being used). I don't think it's
something we should concern ourselves with anyways.

—Sam

-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com



signature.asc
Description: OpenPGP digital signature

Re: [Standards] OTR

[Bartosz Małkowski]

> Wiadomość napisana przez Sam Whited  w dniu 29 gru 2014, 
> o godz. 18:36:
> 
> 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.

Can you explain?
If encrypted stream will be established, then what problems you see? We can’t 
hide fact that OTR stream is established between two entities.

--
Bartosz Małkowski
Tigase Polska
xmpp:bmal...@malkowscy.net



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] OTR

[Dave Cridland]

On 29 December 2014 at 17:12, Sam Whited  wrote:

> Regardless, I think this is out of the scope of what the OTR document
> would define.
>
>
I think it'd be far more useful to define what current OTR usage is, and
what it protects against (and what it doesn't).

Writing what OTR *should* be doing is a whole other document - just as
important, but I'm keener on seeing the first.

Dave.

Re: [Standards] OTR

[Sam Whited]

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

Re: [Standards] OTR

[Sam Whited]

On 12/29/2014 09:07 AM, Bartosz Małkowski wrote:
> I’m thinking if we should add something (optional) to prove that OTR
> Key is trusted. I think about something based on for example OpenPGP
> signatures:
> 
> ...
> 
> Where signature is for example OpenPGP_Sign(otr_key_hash).

OTR doesn't work this way by design. Signing an OTR key via PGP before
verification may give you another channel to determine your trust in the
OTR key (assuming you do trust the PGP key used), but it also destroys
the deniability of the conversation (unless it were done AFTER the OTR
session is already established).

Regardless, I think this is out of the scope of what the OTR document
would define.

—Sam


-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com



signature.asc
Description: OpenPGP digital signature

Re: [Standards] OTR

[Bartosz Małkowski]

Hi!

I’m thinking if we should add something (optional) to prove that OTR Key is 
trusted.
I think about something based on for example OpenPGP signatures:


  E9017BCCF047B363A8ED281F2DE31972BECB3F34
  
hQEMA/cDyEqkT1m7AQf/ejLVE4KnNKJ8yPjMAn9C6OdCrwkZZ50YcrHjRIMkmGYB
…
QFElQwI1RKtS/SBY+CneY0eAIrLFNuW7Y7R/Qpt4jP2+UBpzCyzRzf/PVXfkK9iJ
zmqXfw==
=Aj0L
  


Where signature is for example OpenPGP_Sign(otr_key_hash).

I don’t know if it should be stored somewhere (like VCard) or should be 
generated on request.
I event don’t know if it is necessary or not ;-)

--
Bartosz Małkowski
Tigase Polska
xmpp:bmal...@malkowscy.net



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] OTR

[Bartosz Małkowski]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ok.
I think we should determine goals we want to achieve and more or less features 
of this protocol.
As short list.
- --
Wysłane za pomocą K-9 Mail.
-BEGIN PGP SIGNATURE-
Version: OpenKeychain v3.2beta1

iQFQBAEBCAA6MxxCYXJ0b3N6IE1hbGtvd3NraSAoYm1hbGtvdykgPGJtYWxrb3dz
a2lAdGlnYXNlLnBsPgUCVJmSOAAKCRCoAdab0OzG42V8CADjlmUqyvHLj+l8GxGb
38jUueTkldCY1rOuMILhAtCmFpn5pQkGAzGLKLvQUoxf3FGmjGpD6d6XDQO/UZtk
XYdiUj7SKlpM+kUUP8fewHHMeGsymyS+eA0q6AVSiC2y010MQuJWl9z+JxSziiYg
G4yEbdL3xXBEk7iQbGiMMQ81TF4inB92uN51Xe9SbKF7wuievkjuyu26mDb+AJ4w
R6iwGU3Mgf1jSJZMM3cn0oGJ6om2db4+6s81VOZ0kT/N5fMzX1/EUYuuCX4gD8l4
muXx2p2WwblHHbaZOtFguq7IRGRs8xsGvmdrHnr/NVzkZPsE96GDMuVZoHFIPRp+
8YRa
=vGOI
-END PGP SIGNATURE-

Re: [Standards] OTR

[Winfried Tilanus]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12/19/2014 08:43 PM, Sam Whited wrote:

Hi,

> Sounds great; SamWhited on GitHub.

I just set up the repository and added you and Bartosz:
https://github.com/winfried/XMPP-OTR

Winfried
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJUmYXBAAoJEHZ7UH0X6Ldch1IQALpbpYMrNwWQJWw9ZvkD2fN3
jNAhHgPk8HvuM/V1N2i5x5Lw2HKxCTcpVIl7yhk7L24+kTh73YmVsemx8U+yRhtc
Hwqq+FnKTqRrKhwtYLn/Z7uM/6Quv+PszhgqMsHhDmmG2zDtq4ocP0g2dPs7hmhr
+E71hMlCIk+4qVoLL9dIURH0U3Y2pH7H1KIdD4sRg2V4+NhHDE8jE1T3IaU8ccFm
2Iepg4q6kC2aclf2OAlaHaor7Cfq2Vil047RCTtnwp2FhFaFAlBUZTQScnPRIzsH
RRULRFsrcqJEJH7gI0wpI5tRs9pMpJZu0HZbMKWfCk0nIMXqQ4Lv44kL2tPDTvI4
QfFrvyNtmv/+rynQmCTCx+hfKjURJu6CvpYOjlBQLl/evfn62cWsP+O8ou6piQ90
pl04kRieB5n4RtZOdkiR/+fNKbKNaQdDqoeyC0BZwfXU9ltASOwVgRMLQ0JtyIdz
dyqBrRuJu2W1Vll4CJIaP3WJwdL/sNNV2DwABF/tcPU1jfO90fNSpAvwqaeyVFpO
54buYdBFHe/kIgHf9wiicZWcKi7p581LNbrtHvAxAJ1GQlzwENV8lBIcOXhFkCbL
+wtV4/BvsuJwRfn07McEklTa+d1SxZmoZHQ0qCPiR7wTDadmEId3/FjKh7BXJ7u+
Bi44j01VdO4XjX2k7cwB
=p2LR
-END PGP SIGNATURE-

Re: [Standards] OTR

[Sam Whited]

On 12/23/2014 05:41 AM, Bartosz Małkowski wrote:
> Don’t shoot! I assume that it was just example to illustrate
> solution.

Indeed

On 12/23/2014 06:32 AM, Florian Schmaus wrote:
> Of course. I just don't want to leave those examples uncommented, 
> otherwise people may start considering that as a good/valid example.

You're also correct, of course, no sense in propogating bad design just
for the sake of reducing an example by a line or two.

Thanks!

—Sam

-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com



signature.asc
Description: OpenPGP digital signature

Re: [Standards] OTR

[Florian Schmaus]

On 23.12.2014 11:41, Bartosz Małkowski wrote:
> 
>> Wiadomość napisana przez Florian Schmaus  w dniu 23 gru 
>> 2014, o godz. 11:14:
>>
>> I see two design issues. You already mentioned the custom type value.
>> Never invent new values for defined (top level) elements or new
>> attributes (XEP-0134 § 2.1).
>>
>> Also your custom (OTR) payload should (must?) be encapsulated into a
>> extension element. So your example becomes:
>>
>> 
>>  
>>
>>  
>> 
> 
> Don’t shoot!
> I assume that it was just example to illustrate solution.
> :-)

Of course. I just don't want to leave those examples uncommented,
otherwise people may start considering that as a good/valid example.

- Florian




signature.asc
Description: OpenPGP digital signature

Re: [Standards] OTR

[Bartosz Małkowski]

> Wiadomość napisana przez Florian Schmaus  w dniu 23 gru 
> 2014, o godz. 11:14:
> 
> I see two design issues. You already mentioned the custom type value.
> Never invent new values for defined (top level) elements or new
> attributes (XEP-0134 § 2.1).
> 
> Also your custom (OTR) payload should (must?) be encapsulated into a
> extension element. So your example becomes:
> 
> 
>  
>
>  
> 

Don’t shoot!
I assume that it was just example to illustrate solution.
:-)

--
Bartosz Małkowski
Tigase Polska
xmpp:bmal...@malkowscy.net



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] OTR

[Bartosz Małkowski]

> Wiadomość napisana przez Sam Whited  w dniu 22 gru 2014, 
> o godz. 19:16:
> 
> We couldn't hide the fact that communication happens between A and B,
> but we could hide what type of communication happens. Eg. are messages
> being exchanged, is presence being exchanged, are files being exchanged,
> etc.
> 

Right!
When I was thinking more about it, I have to agree with you.
This is best solution for full e2e encytpion.

--
Bartosz Małkowski
Tigase Polska
xmpp:bmal...@malkowscy.net



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] OTR

[Florian Schmaus]

On 22.12.2014 19:16, Sam Whited wrote:
> On 12/22/2014 11:28 AM, Bartosz Małkowski wrote:
>> I'm not sure we should start new XMPP stream covered by OTR. It 
>> depends on what we want to do. We can't hide that communication 
>> between A and B happens. Does encrypting whole stanzas is worth of 
>> complications?

> eg. after the initial setup / stream initialization:
> 
> 
> 
> ---OTR-ENCRYPTED---
>   could be any type of XMPP message
> ---END-OTR---
> 

I see two design issues. You already mentioned the custom type value.
Never invent new values for defined (top level) elements or new
attributes (XEP-0134 § 2.1).

Also your custom (OTR) payload should (must?) be encapsulated into a
extension element. So your example becomes:


  

  


- Florian



signature.asc
Description: OpenPGP digital signature

Re: [Standards] OTR

[Sam Whited]

On 12/22/2014 11:28 AM, Bartosz Małkowski wrote:
> I'm not sure we should start new XMPP stream covered by OTR. It 
> depends on what we want to do. We can't hide that communication 
> between A and B happens. Does encrypting whole stanzas is worth of 
> complications?

We couldn't hide the fact that communication happens between A and B,
but we could hide what type of communication happens. Eg. are messages
being exchanged, is presence being exchanged, are files being exchanged,
etc.

(this is assuming we were to design some sort of solution where all
wrapper messages look identical, and the actual XMPP stream is encased
within those messages, which isn't necessarily something we want or
don't want to do yet).

eg. after the initial setup / stream initialization:



---OTR-ENCRYPTED---
  could be any type of XMPP message
---END-OTR---


Ignore the `type' as I'm not sure that's something we want either. We'd
have to ensure that whatever we do doesn't break OTR's goal of plausable
deniability. This is just an example based on what I think you were
saying and how it adds so

—Sam

-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com



signature.asc
Description: OpenPGP digital signature

Re: [Standards] OTR

[Bartosz Małkowski]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I'm not sure we should start new XMPP stream covered by OTR. It depends on what 
we want to do. We can't hide that communication between A and B happens. Does 
encrypting whole stanzas is worth of complications?

Dnia 17 grudnia 2014 17:46:18 CET, Winfried Tilanus  
napisał(a):
>On 05-12-14 11:24, Goffi wrote:
>
>Hi,
>
>> Is there any update on this ? Actually the situation is not really
>good today:
>> some client encode XML in OTR, other don't, there is no way to
>advertise OTR
>> support with discovery and there is an OTR specific advertisement way
>(with
>> whitespace-tagged messages). OTR need to work with non XMPP gateways.
>It would
>> be really good to standardize all that...
>
>I had some discussion with Ian Goldberg (one of the OTR-guys) on this.
>Their initial choice was to do OTR in plain messages (with their
>somewhat strange way of discovering support and starting sessions), so
>it would be easy to use OTR in a multi-protocol environment. 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.
>
>Well... I think the first step should be documenting the most common
>case, OTR'ing the content of a message in the OTR way
>
>Winfried

- --
Wysłane za pomocą K-9 Mail.
-BEGIN PGP SIGNATURE-
Version: OpenKeychain v3.2beta1

iQFQBAEBCAA6MxxCYXJ0b3N6IE1hbGtvd3NraSAoYm1hbGtvdykgPGJtYWxrb3dz
a2lAdGlnYXNlLnBsPgUCVJhGpQAKCRCoAdab0OzG44/JB/0ZNJCOTYlLaNqENOox
ybj8Qosn7QD+El/W0UE7yrHByAg5BwrjzyRpCitvWE7CT8AfHPtJHx9IBTj2zdSW
U2BXKeO4rFrCwt1UEm2EquPZYyAduYuqQ7yx4sl4C77qF5uz7H/yYck3b0i+v6Yu
5JZVGB5p/fVFSyYOZLOqRGrYVeWIZoiKINTtAlOlFqcUmP2m9iKVm/ovrdIDB43i
UYQ+f1LdTp+mG42WYrEmdOvnKzsiDqARic/wxNO+E6YGiGVKat2ETZqT1WN1hQ1O
bTj/SoeKh3pjq8opMpDZFXE27QKHvP6Qhu5WKVk7UL8AYak1eh9I8hEzpHedsxDS
zt5C
=tO/+
-END PGP SIGNATURE-

Re: [Standards] OTR

[Dave Cridland]

On 19 December 2014 at 20:31, Mathieu Pasquet  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)
>

Re: [Standards] OTR

[Mathieu Pasquet]

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.
> 
> 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.

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)


pgpqhPHsjL1mf.pgp
Description: PGP signature

Re: [Standards] OTR

[Sam Whited]

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



signature.asc
Description: OpenPGP digital signature

Re: [Standards] OTR

[Sam Whited]

On 12/17/2014 11:50 AM, Winfried Tilanus wrote:
> Do you have a github account? If so, can you mail me your GitHub
> names, then I open a repostory for it and make you project members...

Sounds great; SamWhited on GitHub.

> I can setup a skeleton (etc)

Sounds good; I've started to actually work on this several times, but
haven't made any substantial progress (busy time of year and all).

Thanks for following up and getting this rolling / helping to keep us
all on track.

—Sam


-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com



signature.asc
Description: OpenPGP digital signature

Re: [Standards] OTR

[Winfried Tilanus]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07-11-14 22:16, Bartosz Małkowski wrote:

Bartosz and Sam,

> I'm in too. I haven't experience with writing xep, but I'm
> interested in securing communication.

Do you have a github account? If so, can you mail me your GitHub
names, then I open a repostory for it and make you project members...

I can setup a skeleton (etc)

Winfried
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJUkbQ8AAoJEHZ7UH0X6LdcCHQQAKzFaNhg8yWXyWSug0fl2aZY
CHw9TrbyRp3O/FE/ZKSpPlbOH669SbNGUFJXChF1wKt/7EebTyD+YIhNKZHRO+pC
NM74mdqEiDVZQf14RP6aStsl5edySQ66Ga2NDNPv1lnNNBEJux3kO2+AhHkDVpSo
IgSMeIzYNGtp+lkgPanuTjQcNYw+kqEfNq1naqD0/zY7dcMrrD9jdM3fzxZmlKHW
95MzugTIEnRCPmyNY0CQ/g/54eDSmKmuEmmomwaWOvstIwPVO10z1JPfd+PJTLq8
NohmoZe8ic7uuKE8sL/6Jiz9ed09BYXYXVM4XZgA1jr4Rve308pTsU8oAB9EPLuc
/cTqgRA3CGicaVjFAT42luAsLLOB0bIywDKFFbu6daXnGSPJEa7f/JbYocL5mLQn
xP5JK8fwVWuyzezMZsIocsEslxPPvT0gvWSZOcxKFRMgPh9QdobM6mDR3xWy033L
ZOkwJU3Ukm96+uEPct/jJTLZNbS0jP4G03BkHoT2wCha/JV7UKMTa+JsclMOtAk0
UOaokqPQT1ho8XMawnM2/1rgYbZM1L1nkKxYI0ATIVzWbYSKXvF5L3x6B+qiEIWf
8WS2wNIxDc2vjRB18fsY4jdGwMOyK6zMv+YShlSkRDJhE891Ea7AEhph9ZBj2wxB
OXTISJO8M5l3EC13Fz8F
=dqKQ
-END PGP SIGNATURE-

Re: [Standards] OTR

[Winfried Tilanus]

On 05-12-14 11:24, Goffi wrote:

Hi,

> Is there any update on this ? Actually the situation is not really good 
> today: 
> some client encode XML in OTR, other don't, there is no way to advertise OTR 
> support with discovery and there is an OTR specific advertisement way (with 
> whitespace-tagged messages). OTR need to work with non XMPP gateways. It 
> would 
> be really good to standardize all that...

I had some discussion with Ian Goldberg (one of the OTR-guys) on this.
Their initial choice was to do OTR in plain messages (with their
somewhat strange way of discovering support and starting sessions), so
it would be easy to use OTR in a multi-protocol environment. 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.

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

Winfried

Re: [Standards] OTR

[Goffi]

G'day

Le vendredi 7 novembre 2014, 09:55:43 Dave Cridland a écrit :
> In an internal discussion at Surevine, OTR was mentioned, and it was moaned
> that OTR usage in XMPP isn't actually documented anywhere we know of.
> 
> Is anyone willing to help work on a XEP to explain how to run OTR over
> XMPP, and catalogue limitations etc?
> 
> Dave.

Is there any update on this ? Actually the situation is not really good today: 
some client encode XML in OTR, other don't, there is no way to advertise OTR 
support with discovery and there is an OTR specific advertisement way (with 
whitespace-tagged messages). OTR need to work with non XMPP gateways. It would 
be really good to standardize all that...

Cheers
Goffi

Re: [Standards] OTR

[Dave Cridland]

Yay for steganography.

On 17 November 2014 13:59, Stefan Strigler 
wrote:

> I see, we're having a fruitful discussion. This was part of the master
> plan. ;)
>
> 2014-11-17 13:52 GMT+01:00 Winfried Tilanus :
>
>> On 11/14/2014 10:25 PM, Genghis Khan wrote:
>>
>> Hi,
>>
>> > Bobs Suicide Letter has a typo "an horrible".
>>
>> Well, if that is the only typo / strange thing in the language you have
>> found, I think I did pretty well, given that English is not my native
>> language. ;-)
>>
>> Winfried
>>
>
>

Re: [Standards] OTR

[Stefan Strigler]

I see, we're having a fruitful discussion. This was part of the master
plan. ;)

2014-11-17 13:52 GMT+01:00 Winfried Tilanus :

> On 11/14/2014 10:25 PM, Genghis Khan wrote:
>
> Hi,
>
> > Bobs Suicide Letter has a typo "an horrible".
>
> Well, if that is the only typo / strange thing in the language you have
> found, I think I did pretty well, given that English is not my native
> language. ;-)
>
> Winfried
>

Re: [Standards] OTR

[Winfried Tilanus]

On 11/14/2014 10:25 PM, Genghis Khan wrote:

Hi,

> Bobs Suicide Letter has a typo "an horrible".

Well, if that is the only typo / strange thing in the language you have
found, I think I did pretty well, given that English is not my native
language. ;-)

Winfried

Re: [Standards] OTR

[Kevin Smith]

On 14 Nov 2014, at 22:51, Dave Cridland  wrote:
> Well, we're so far off topic now it hardly matters.
> "An horrible" is correct English, like "an historical", and so on. But nobody 
> does it.

Well, kinda. One uses ‘An’ where there's a spoken vowel sound. Words beginning 
with ‘h’ where it’s silent should effect the use of ‘an’, words beginning with 
‘h’ where it’s sounded should cause an ‘a’ to be used.

At least in modern English the ‘h’ in ‘historical’ is sounded, so it’s correct 
to write ‘a’ rather than ‘an’ preceding it. I think that historically the ‘h’ 
in some words was less pronounced than it is today, leading to a historical use 
of ‘an (h)istorical use’.

Or, in other words, don’t worry about it, use ‘a’ if you’d pronounce the ‘h’ or 
‘an’ if you’d elide it.

Disclaimer: I am not a language lawyer, please consult your local grammarian.

/K

Re: [Standards] OTR

[Dave Cridland]

Well, we're so far off topic now it hardly matters.

"An horrible" is correct English, like "an historical", and so on. But
nobody does it.

As for who Alice and Bob are, they're the characters introduced by Rivest
et al in their early crypto papers, and most authors followed the
convention, adding various other threat characters as time went on.
On 14 Nov 2014 21:25, "Genghis Khan"  wrote:

> On Sun, 09 Nov 2014 10:46:58 +0100
> Winfried Tilanus  wrote:
>
> > On 07-11-14 15:39, Stefan Strigler wrote:
> >
> > Hi,
> >
> > > But will you mention http://thealiceandbobsuicide.org ?
> >
> > That is quite a dilemma, you know, I am still missing Alice and Bob...
> >
> > Winfried
>
> Who are Alice and Bob?
>
> Bobs Suicide Letter has a typo "an horrible".
>

Re: [Standards] OTR

[Ralph Meijer]

On 2014-11-14 22:25, Genghis Khan wrote:
> On Sun, 09 Nov 2014 10:46:58 +0100
> Winfried Tilanus  wrote:
> 
>> On 07-11-14 15:39, Stefan Strigler wrote:
>>
>> Hi,
>>
>>> But will you mention http://thealiceandbobsuicide.org ? 
>>
>> That is quite a dilemma, you know, I am still missing Alice and Bob...
>>
>> Winfried
> 
> Who are Alice and Bob?
> 
> Bobs Suicide Letter has a typo "an horrible".

As always, that depends on your pronunciation [1,2].

[1]<
http://www.oxforddictionaries.com/words/why-do-such-words-as-hour-and-honest-have-a-silent-h>
[2]


-- 
ralphm

Re: [Standards] OTR

[Genghis Khan]

On Sun, 09 Nov 2014 10:46:58 +0100
Winfried Tilanus  wrote:

> On 07-11-14 15:39, Stefan Strigler wrote:
> 
> Hi,
> 
> > But will you mention http://thealiceandbobsuicide.org ? 
> 
> That is quite a dilemma, you know, I am still missing Alice and Bob...
> 
> Winfried

Who are Alice and Bob?

Bobs Suicide Letter has a typo "an horrible".

Re: [Standards] OTR

[Winfried Tilanus]

On 07-11-14 15:39, Stefan Strigler wrote:

Hi,

> But will you mention http://thealiceandbobsuicide.org ? 

That is quite a dilemma, you know, I am still missing Alice and Bob...

Winfried

Re: [Standards] OTR

[Bartosz Małkowski]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I'm in too. I haven't experience with writing xep, but I'm interested in 
securing communication.
- --
Wysłane za pomocą K-9 Mail.
-BEGIN PGP SIGNATURE-
Version: OpenKeychain v3.1.2

iQFQBAEBCAA6MxxCYXJ0b3N6IE1hbGtvd3NraSAoYm1hbGtvdykgPGJtYWxrb3dz
a2lAdGlnYXNlLnBsPgUCVF02kQAKCRCoAdab0OzG416DB/9aeRmZyaS5YvwAyj3T
byJiSQfmMKvc3E6W69R2Udt7HWU0dGEKZT3yt9gA7cwZs6plkPncp5ZzmAxOHPL4
IdC708GA+TgnLFgxy/NjprwKHmHEZZxxADvcS6JUbx1xdnRrmyR+cUIYRDh+WidW
f/eyFkO4np8HqkY/X2HD1YVLRTKMxlf5pat7HVTDGmSBOWhNQbrNSYjKo+1A7Uy7
8O4tYwYkH77Lj5SsLFlsSnChKIaiYuKYm+bmar3GouKNe45CUhcy2x8t4KvJ7liE
1qQP74RjlP9bmnGsyZPdjAcFgihok0+drWS3NzRrPiFUhPgX+EcwFBBJzG05lMMj
IIoT
=0WcU
-END PGP SIGNATURE-

Re: [Standards] OTR

[Sam Whited]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 11/07/2014 04:55 AM, Dave Cridland wrote:
> Is anyone willing to help work on a XEP to explain how to run OTR
> over XMPP, and catalogue limitations etc?

I would be happy to help in any way that I can. I have not authored an
XEP before, but have implemented quite a few and work with XMPP and
OTR on a regular basis.

—Sam

- -- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJUXSsaAAoJEELmVuezbjL3mUIP/jrpdtettXhl5X/XsOXvvuz4
phfzJjtr6eMK0BaPMftZM4GG8gH5Jn/ggHXoDgczaY96oXT2PL3HW20c11ZBi7xg
awq1+NDvqvI5nUpxtLJuoTQvxeFvVbCn1OJCeC167/K2cgPs1BJl4Ey5Pkpo2fYa
ekB3WUIpHZpDDZYsDwq9Hu0bCM2//llNLe3k6lJM35X44XryQZ68LFZ57z/6ca5r
3qHtf1k9eeLGDzWim0gHSKXK0C8ppD1wur0+CBflp9lmg+snXKD0EffSoybwtssc
msgx+QEJqboBdjWkP4p8+msxDWpRusw2caajuDIvTxpvSEqWtdgEl8/LIdDH/yWX
eTWdVBtYikszttzsKtFvJtDzPLFVbDauKRafN8HyrEOnMu1LbzIZzpPJsJCqm5DI
y+02S1g15uqSmRwSFgIvmndy5dW2boFMiEObtG8AO3zH+7krp35GwOIQXkL6h/Zf
7/tLm5eNEcHzBAYwyPQ5trziGiOk+Gvo0wPzaOrNbBvczYzKurCxjv2p1OTUu2tH
aR52ieawrvZIs3IFOuEEDEBgcYbUU56cpO5t2mOWPVgvj5M32+IJIuZTyDkV3dRB
MrvnxAJRHQfwg12mSuOBTx3S0Gb+yx4Che8CLVUgWXKP6K3Ale9c0acASgvKxsdN
VhdRfTX5EJX5GnojdkV/
=R8JT
-END PGP SIGNATURE-

Re: [Standards] OTR

[Bartosz Małkowski]

> Wiadomość napisana przez Ashley Ward  w dniu 7 lis 
> 2014, o godz. 16:32:
> 
> 
> Just as long as Romeo and Juliet don’t commit suicide too. Wait, what’s that 
> you say…?

In worst case we still have Kermit the Frog, Animal, GOnzo and Dr. Teeth 
(https://wiki.asterisk.org/wiki/display/AST/AMI+v2+Specification).

-- 
Bartosz Małkowski
Tigase Polska
xmpp:bmal...@malkowscy.net



smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] OTR

[Dave Cridland]

On 7 November 2014 17:00, Graham King  wrote:

>
>
> On 14-11-07 07:32 AM, Ashley Ward wrote:
> >
> > Just as long as Romeo and Juliet don’t commit suicide too. Wait, what’s
> that you say…?
> >
>
> Surely Julius Caesar (http://shakespeare.mit.edu/julius_caesar/index.html)
> would be the appropriate source for examples, being the only person to have
> both a Shakespeare play and a cipher named after him.
>

And a salad. Isn't there a hotel in Vegas, too?

Re: [Standards] OTR

[Graham King]

On 14-11-07 07:32 AM, Ashley Ward wrote:
> 
> Just as long as Romeo and Juliet don’t commit suicide too. Wait, what’s that 
> you say…?
> 

Surely Julius Caesar (http://shakespeare.mit.edu/julius_caesar/index.html) 
would be the appropriate source for examples, being the only person to have 
both a Shakespeare play and a cipher named after him.

Re: [Standards] OTR

[Ashley Ward]

On 7 Nov 2014, at 15:27, Peter Saint-Andre - &yet  wrote:
> 
> On 11/7/14, 7:39 AM, Stefan Strigler wrote:
>> 2014-11-07 13:02 GMT+01:00 Winfried Tilanus > >:
>> 
>>On 11/07/2014 10:55 AM, Dave Cridland wrote:
>> 
>>> Is anyone willing to help work on a XEP to explain how to run OTR over
>>> XMPP, and catalogue limitations etc?
>> 
>>Though I am quite flooded with work right now, I am willing to help with
>>that project. Ping me to discuss startingpoints etc..
>> 
>> 
>> But will you mention http://thealiceandbobsuicide.org ?
> 
> Wow, what a sad story. :(

Just as long as Romeo and Juliet don’t commit suicide too. Wait, what’s that 
you say…?

smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] OTR

On 11/7/14, 7:39 AM, Stefan Strigler wrote:

2014-11-07 13:02 GMT+01:00 Winfried Tilanus mailto:winfr...@tilanus.com>>:

On 11/07/2014 10:55 AM, Dave Cridland wrote:

> Is anyone willing to help work on a XEP to explain how to run OTR over
> XMPP, and catalogue limitations etc?

Though I am quite flooded with work right now, I am willing to help with
that project. Ping me to discuss startingpoints etc..


But will you mention http://thealiceandbobsuicide.org ?


Wow, what a sad story. :(

Re: [Standards] OTR

[Stefan Strigler]

2014-11-07 13:02 GMT+01:00 Winfried Tilanus :

> On 11/07/2014 10:55 AM, Dave Cridland wrote:
>
> > Is anyone willing to help work on a XEP to explain how to run OTR over
> > XMPP, and catalogue limitations etc?
>
> Though I am quite flooded with work right now, I am willing to help with
> that project. Ping me to discuss startingpoints etc..
>

But will you mention http://thealiceandbobsuicide.org ?

Re: [Standards] OTR

[Winfried Tilanus]

On 11/07/2014 10:55 AM, Dave Cridland wrote:

Hi,

> Is anyone willing to help work on a XEP to explain how to run OTR over
> XMPP, and catalogue limitations etc?

Though I am quite flooded with work right now, I am willing to help with
that project. Ping me to discuss startingpoints etc..

Winfried

Re: [Standards] OTR-like protocols in XMPP

[Jon Kristensen]

On 02/26/2013 04:28 PM, Simon McVittie wrote:

That seems a lot more XMPP-ish than "plain OTR", and addresses a concern
I've always had about OTR (that it's defined in terms of a stream of
plain-text messages, making it protocol-agnostic but unable to interact
with individual protocols' features).

However, if this is not wire-protocol-compatible with "real OTR", does
it have any particular advantages over previous XMPP work on end-to-end
TLS, with X.509 certificates that are typically self-signed and used
mainly as a vehicle for key material?

My understanding had been that the main advantage of OTR over TLS is
that it gets some "network effect" from the OTR Pidgin plugin being
somewhat widely-deployed; if that advantage isn't present, would it be
better for security to reuse widely-tested TLS libraries (OpenSSL,
GNUTLS etc.) rather than trying to get all the subtleties of crypto
right in domain-specific code?


One benefit of my protocol would be that the same "identity" (DSA key)
can be used to provide transparent OTR compatibility, since the user
could use her same credentials to speak OTR. However, I think that
something like TLS should be used instead, as long as the appropriate
features (such as deniability, and perhaps also forgeability - more on
that later) can be supported.


Which of the security properties desired by
 does
this OTR-like protocol have, and does it have any more that are
desirable but not specified in that document? (For that matter, which
does OTR have?)


Since you're curious, I will give you my take on the OTR protocol in
relation to the requirements of E2E-REQ, as well as the requirements
nicely presented in your posts to the Telepathy mailing list. Please
note that I am not a cryptographer either, so I may very well be wrong
in my assertions.

Let's start by taking a look at the security requirements of E2E-REQ.
I believe that you are right in that OTR provides confidentiaility
and integrity. I would also say that OTR does support replay
protection (through the counter value) as well as perfect forward
secrecy (through continuous renegotiation of shared secrets, each
time involving a random number). Trust can be established through the
comparing the session identifier or by performing a Socialist
Millionarie's Protocol query. Authentication is done through DSA keys.
As the authenticated key exchange does not reveal the key to any
intermediate entity, it should allow for identity protection as well.
Furthermore, I guess that - since an attacker must have access to the
private DSA key, guess the secret value within a small window of time,
and, even if the attacker manages to put herself in the middle, must
be able to guess the occasional Socialist Millionaire's Protocol
query - OTR could be considered to fulfill the robustness requirement.
OTR defines a syntax for announcing which versions of the protocol are
supported, allowing for upgradability.

Summary:

+-+-+
| Security requirement| OTR |
+-+-+
| Confidentiality |  Y  |
+-+-+
| Integrity   |  Y  |
+-+-+
| Reply protection|  Y  |
+-+-+
| Perfect forward secrecy |  Y  |
+-+-+
| Trust   |  Y  |
+-+-+
| Authentication  |  Y  |
+-+-+
| Identity protection |  Y  |
+-+-+
| Robustness  |  Y  |
+-+-+
| Upgradability   |  Y  |
+-+-+

There is another set of requirements defined in E2E-REQ: Application
requirements. OTR can, as previously mentioned, only be used to
protect the content of the message  element, so it does not
fulfill the generality requirement. As the implementation of OTR is
quite straight-forward, and there are some libraries available, I
would say that it's implementable. The popular use of Pidgin-OTR has
indicated that OTR is usable enough to gain widespread adoption. OTR
mentions the use of Diffie-Hellman key exchanges for shared secret
negotiation is a cheap, so I would assume that the protocol is
efficient. In order to be flexible, OTR would have to "be compatible
with a variety of existing and future cryptographic algorithms and
identity certification schemes". OTR assumes the use of DSA keys,
Diffie-Hellman key exchanges, and AES-128-CTR, so I don't think that
it qualifies. Offline messages can be decrypted later with OTR
(assuming that the shared secret is still available).

Summary:

+-+-+
| Application requirement | OTR |
+-+-+
| Generality  |  N  |
+-+-+
| Implementability|  Y  |
+-+-+
| Usability   |  Y  |
+--

Re: [Standards] OTR-like protocols in XMPP (was: Self Introduction)

[Simon McVittie]

On 26/02/13 14:50, Jon Kristensen wrote:
> In the process of prototyping Yabasta, I have "designed" an OTR-like
> protocol[3] that, while based on OTR, differs from OTR in a number of
> ways. [...] any XML payloads can
> be protected (not just message bodies).

That seems a lot more XMPP-ish than "plain OTR", and addresses a concern
I've always had about OTR (that it's defined in terms of a stream of
plain-text messages, making it protocol-agnostic but unable to interact
with individual protocols' features).

However, if this is not wire-protocol-compatible with "real OTR", does
it have any particular advantages over previous XMPP work on end-to-end
TLS, with X.509 certificates that are typically self-signed and used
mainly as a vehicle for key material?

My understanding had been that the main advantage of OTR over TLS is
that it gets some "network effect" from the OTR Pidgin plugin being
somewhat widely-deployed; if that advantage isn't present, would it be
better for security to reuse widely-tested TLS libraries (OpenSSL,
GNUTLS etc.) rather than trying to get all the subtleties of crypto
right in domain-specific code?

Which of the security properties desired by
 does
this OTR-like protocol have, and does it have any more that are
desirable but not specified in that document? (For that matter, which
does OTR have?)

It seems to me as though many of OTR's frequently-stated advantages
(such as perfect forward secrecy and repudiability) are advantages over
older techniques like individually PGP-signing messages (XEP-0027, which
has many other flaws), but are not advantages over TLS, which shares
those properties. Is this the case?

Last time I looked at supporting OTR and/or XTLS in the Telepathy
framework, I wrote

and

to try to articulate what our goals for end-to-end encryption might be,
and which of those goals are satisfied by each of XTLS and OTR.

As far as I could work out in message 006135, XTLS offers just as much
deniability as OTR (anyone who can understand a message stream enough to
cite it as evidence of a conversation could also have faked the entire
conversation). Is this the case, or was I missing something important?

Regards,
S