Re: [Standards] OTR

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

Re: [Standards] OTR

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

Re: [Standards] OTR

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

Re: [Standards] OTR

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

Re: [Standards] OTR

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/00135

Re: [Standards] OTR

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 useles

Re: [Standards] OTR

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 s

Re: [Standards] OTR

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

Re: [Standards] OTR

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://gi

Re: [Standards] OTR

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 p

Re: [Standards] OTR

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

Re: [Standards] OTR

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

Re: [Standards] OTR

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

Re: [Standards] OTR

> 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

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 thu

Re: [Standards] OTR

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

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

Re: [Standards] OTR

-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

Re: [Standards] OTR

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 w

Re: [Standards] OTR

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

Re: [Standards] OTR

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

Re: [Standards] OTR

* 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

Re: [Standards] OTR

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

Re: [Standards] OTR

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

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

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 deni

Re: [Standards] OTR

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

Re: [Standards] OTR

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

Re: [Standards] OTR

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 a

Re: [Standards] OTR

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 thi

Re: [Standards] OTR

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

Re: [Standards] OTR

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

Re: [Standards] OTR

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

Re: [Standards] OTR

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

Re: [Standards] OTR

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

Re: [Standards] OTR

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

Re: [Standards] OTR

> 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

Re: [Standards] OTR

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

Re: [Standards] OTR

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 th

Re: [Standards] OTR

-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, Wi

Re: [Standards] OTR

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 pr

Re: [Standards] OTR

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 pro

Re: [Standards] OTR

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

Re: [Standards] OTR

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

Re: [Standards] OTR

-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

Re: [Standards] OTR

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

Re: [Standards] OTR

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

Re: [Standards] OTR

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 ha

Re: [Standards] OTR

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 languag

Re: [Standards] OTR

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

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 sile

Re: [Standards] OTR

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

Re: [Standards] OTR

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 Bo

Re: [Standards] OTR

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 S

Re: [Standards] OTR

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

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

Re: [Standards] OTR

-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

Re: [Standards] OTR

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

Re: [Standards] OTR

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 appropriat

Re: [Standards] OTR

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

Re: [Standards] OTR

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 e

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? Th

Re: [Standards] OTR

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 pro

Re: [Standards] OTR

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

[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-like protocols in XMPP

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

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

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 "