XSF Discussion - 2018-08-02


  1. jonasw

    18:38:57 lovetox> one could do it that way, but then you would have to check from time to time, if your db stored prekeys are really the ones that are published you have to do that anyways because PEP services tend to "forget" your stuff from time to time

  2. Ge0rG

    Isn't it awesome how the xmpp and OMEMO identity models extend each other?

  3. jonasw

    I sense sarcasm

  4. Guus

    Ge0rG, sarcasme? Nahhh...

  5. Guus raises fist to autocorrect.

  6. flow

    Ge0rG, while it's trivial to change that?

  7. Ge0rG

    flow: one of the strong opinions that I hold is: if you want cryptographic identities, you should have a protocol using those as a first-level citizen, not tacked upon another routing protocol

  8. flow

    Ge0rG, I know. But what do you suggest an xmpp based e2ee protocol should do? Using the public key as one's JID localpart?

  9. Ge0rG

    flow: I think there needs to be a stronger cryptographic link between the user identity, the key material and the JID.

  10. Ge0rG

    flow: if I was doing things, I'd go with user keys that contain a signature of the JID, plus maybe an S/MIME like CA system

  11. flow

    "signature of the JID"?

  12. flow

    or a signed statement of the user's JID?

  13. Ge0rG

    The latter.

  14. flow

    I'm also not sure how that prove ownership of the JID

  15. Ge0rG

    It doesn't. But it means you can't move a key to a different JID

  16. flow

    And preventing that is desirable because?

  17. Ge0rG

    flow: I'm not sure. It's just a bad gut feeling, nothing specific. Maybe abuse of sloppy implementations leading to impersonation of other users...

  18. flow

    Ge0rG, So if you would be designing things, the main difference would be an additional signed statement of the JID and that only because of a gut feeling that it would possibly beneficial. Or did I miss something?

  19. Ge0rG

    flow: the main difference is: I would go with a two or three layer architecture. A user has their identity key (or primary device key), and signs their secondary keys. Plus a means to have a CA signing user keys bound to JIDs

  20. flow

    Let me focus on the CA thingy first: What is the advantage over a CA verifying the "identity" by signing user keys compared to the public key in PEP? If you consider Let's Encrypt, then LE just checks that you have control over a certain "namespace", which is pretty much what public key in PEP provides.

  21. flow

    What additional benefit do you envison could a CA provide?

  22. Ge0rG

    flow: good point. A public CA doesn't help in needing to trust the server, and no amount of OOB will help

  23. Ge0rG

    A corporate CA might help, but then it's probably operated by the same people the server is

  24. Ge0rG

    The major problem I see with OMEMO is multi-device key management. A client message of "You seem to have added a new device at 12:10, with the following fingerprint: ... - correct? [Yes] [No]" with a cross-key signing is vastly better than forcing every one of your contacts to manually verify that fact.

  25. Syndace

    Ge0rG: I like the idea a lot! Has this been discussed before?

  26. Ge0rG

    Syndace: I suggested that to daniel back when OMEMO was being designed.

  27. Ge0rG

    The idea was not approved.

  28. Syndace

    Hmm, is there a mailing list thread or do you remember the reason?

  29. Ge0rG

    Apparently because automatically trusting a new key which is signed by your friend's old key is a security issue.

  30. Ge0rG

    Or maybe because signing keys is not trivial. Or both.

  31. daniel

    Why not share the key?

  32. daniel

    That seems easier than cross signing

  33. Ge0rG

    daniel: what exactly do you mean by "share the key"

  34. daniel

    Using the same key

  35. daniel

    Like OX

  36. Ge0rG

    daniel: ah, a user key as opposed to a device key

  37. Syndace

    How do you get the key to the new device

  38. Ge0rG

    Syndace: QR code with a red border:P

  39. daniel

    Yeah. Or put it in the cloud

  40. Syndace

    True, but then again, if one device gets compromised, all of them are

  41. Ge0rG

    Syndace: yes

  42. Ge0rG

    Syndace: but that doesn't matter in practice.

  43. daniel

    And that's the same as cross signing

  44. Ge0rG

    Syndace: if one if your devices is compromised, the attacker gets the local history of that device and everything sent to you

  45. Syndace

    The cross signing issues don't matter as well

  46. Ge0rG

    daniel: as stated above, I prefer user keys to device keys.

  47. Ge0rG

    daniel: I thought that OMEMO required device keys anyway, so a two-tier key arch was my second best suggestion

  48. jonasw

    daniel, no, it’s not the same as cross-signing. a malicious key added by cross-signing can be removed individually and the damage is contained. if all your devices share the same key, you have to roll your key over entirely to fix the damage. right?

  49. Ge0rG

    or cross-signing

  50. daniel

    How do you revoke a key though

  51. Ge0rG

    start with a new user key.

  52. daniel

    I mean in case of device keys

  53. daniel

    What I'm saying is that I don't see the benefits of cross signing of sharing the private key

  54. Ge0rG

    daniel: you *could* add revocations to cross-signatures.

  55. jonasw

    hm

  56. Ge0rG

    the point that I made in the beginning (and am still making) is: with the user managing their own keys, you have O(1) key management overhead. With the contacts managing the user's keys you have O(N) for N contacts, and you have zero decision agency

  57. Ge0rG

    did Daniel just buy a new Pixel phone, or is the NSA impersonating? How am I supposed to know?

  58. daniel

    It's not news that trust is hard

  59. Ge0rG

    daniel: and you are making it even harder.

  60. daniel

    Than?

  61. daniel

    Otr?

  62. Ge0rG

    daniel: harder than needed

  63. daniel

    Otr allowed for funny questions that I didn't knew the answer to

  64. daniel

    That was pretty fun

  65. Ge0rG

    daniel: are you still on holiday? Have a nice time and let's talk seriously when you're back

  66. flow

    Ge0rG, I still don't know how "xmpp and OMEMO identity models extend[ing] each other" fits into the picture, and what you suggest should change

  67. Ge0rG

    flow: apparently it wasn't clear to everybody. My statement was utterly sarcastic.

  68. flow

    Ge0rG, so besides cross-signing keys, you are happy with omemo?

  69. Ge0rG

    flow: I'm happy with ignoring its existence.

  70. flow

    It appears you are not very good at it

  71. Ge0rG

    flow: for practical matters, I am.

  72. Ge0rG

    obviously, I can't completely ignore it with my Council member hat on.

  73. Syndace

    alright honestly, why is the hate against omemo so huge in this whole community? I haven't had problems with it, not one single time.

  74. Syndace

    because checking fingerprints is a pain? because "This message is OMEMO encrypted, your client does not seem to support it"?

  75. daniel

    A little bit of both probably. And people also like to complain about things

  76. Syndace

    that's far from enough reason to spread such hate

  77. daniel

    That's the internet

  78. Kev

    I don't think anyone /hates/ it, it's a protocol. I think several people see there are issues with it.

  79. Ge0rG

    And other people think that E2EE should be enforced upon everyone, which leads to hate indeed.

  80. MattJ

    that isn't specific to OMEMO

  81. Ge0rG

    E2EE by means of OMEMO.

  82. Ge0rG

    And then non-technical users complain that their messages don't get delivered, and we have one *additional* place to look for.

  83. MattJ

    Someone spent months trying to contact me once, but they had mod_require_otr enabled on their server and I couldn't reply

  84. MattJ

    and the only contact I had for them was their JID

  85. MattJ

    I had a similar situation where I logged into my account with Conversations to test something, and then a bunch of people couldn't message me anymore

  86. Ge0rG

    MattJ: should've sent them "?OTRv2 hi please disable mod_require_otr"

  87. jonasw

    Ge0rG, more than one place, because OMEMO is such a mess of moving parts

  88. Ge0rG

    MattJ: yes, publishing an OMEMO pre-key wreaks havoc to all your other clients.

  89. MattJ

    I don't consider myself an "OMEMO hater" though, I think I've rarely mentioned it... I've many other things to complain about before I could get to that :)

  90. MattJ

    jonasw, is it such a mess?

  91. Syndace

    > MattJ: yes, publishing an OMEMO pre-key wreaks havoc to all your other clients. What?

  92. jonasw

    MattJ, with the unstable PEP implementations out there and inconsistency in handling of OMEMO messages with and without surrogate body (on all levels), yes

  93. MattJ

    Both seem like things that could be relatively easily fixed

  94. MattJ

    A non-PEP key distribution protocol would be pretty trivial

  95. Ge0rG

    MattJ: > Both seem like things that could be relatively easily fixed The story of XMPP.

  96. MattJ

    Ge0rG, some things are more easily fixed than others :)

  97. MattJ

    OMEMO does not seem like our worst problem by far

  98. MattJ

    Syndace, some of my clients don't support OMEMO, I don't particularly want to use OMEMO either

  99. Syndace

    What about: When starting a new chat, the client sends the messages unencrypted in the message body AND encrypted using OMEMO at the same time and based on whether the response is OMEMO encrypted the client decides whether to stick with omemo or go on plaintext

  100. MattJ

    Syndace, I think my problem is more with the way Conversations enforces it, than the protocol

  101. Ge0rG

    Syndace: doesn't work in multi-client scenarios

  102. Syndace

    What does mutli client scenario mean? group chat?

  103. MattJ

    Syndace, multiple clients on the same account

  104. MattJ

    which just about every XMPP developer has

  105. Syndace

    True, all of them need OMEMO to receive the message

  106. Ge0rG

    all of them need to support OMEMO and have their prekey published and trusted by the sender

  107. Ge0rG

    that's a large number of moving parts.

  108. Syndace

    yeah i see

  109. Ge0rG

    especially if you test multiple desktop clients, multiple mobile clients and do web sessions from time to time

  110. Ge0rG

    so you either end up with one client polluting your PEP with keys, leading to all your contacts sending you garbage, or with other corner cases of the protocol

  111. Kev

    As long as clients don't go enabling omemo for you automatically, which would obviously be broken, I don't see this as particular problem.

  112. Kev

    Or, rather, not something that can be solved.

  113. Kev

    Because once you hit the "I want to e2e" switch, you *want* to avoid non-e2e clients getting plaintext.

  114. Ge0rG

    Kev: I've heard that Conversations will auto-enable E2EE.

  115. Kev

    And so you're just not going to flick that switch if you want to use non-e2e clients. Irrespective of whether that's omemo or other.

  116. jonasw

    Ge0rG, Conversations *does* auto-enable E2EE

  117. jonasw

    even if no keys are seen.

  118. jonasw

    (you get a warninng and an option to disable when you send a message then)

  119. Ge0rG

    Besides of this, there is no secure way to communicate the status of that hypothetical "I want to e2ee" switch.

  120. jonasw

    't

  121. Ge0rG now attempts to rhyme "e2ee" to "break free"

  122. Kev

    Ge0rG: Well, there's HSTS-ish at least.

  123. Kev

    Ge0rG: You want to rhyme it to "to break free"

  124. Kev

    Then it works.

  125. Ge0rG

    Kev: except that HSTS relies on a semi-corrupt CA hierarchy

  126. MattJ

    Syndace, and here you get the problem described by XMPP developers. When we (e.g. I'm a server developer) have to deal with users who encounter these problems and want to know why their messages are not being delivered... it's extremely difficult to help them

  127. Kev

    Do I not mean HSTS? I mean "Ok, I'm telling you now, don't use me in the future if I stop encrypting", anyway.

  128. Ge0rG

    I don't want to be used by Kev

  129. Ge0rG

    irregardless of E2EE

  130. MattJ

    Syndace, I think that could be solved with better tooling (as well as improving client UIs)

  131. jonasw

    Ge0rG, lol

  132. Kev

    That's what you think, but you're mistaken (Ge0rG)

  133. jonasw

    get a room

  134. Ge0rG

    jonasw: if only MUC invitations were working reliably.

  135. Syndace

    I think it's a very bad idea that clients enable encryption even if they know that one of the receiving devices does not support it. Silently dropping messages is a super bad idea confusing WhatsApp-level users

  136. Ge0rG

    Syndace: there is no notion of "user's devices" so it's impossible to know whether all devices support OMEMO

  137. jonasw

    Syndace, problem is: if you don’t do that, servers (which are the bad guys™ in the e2ee scenario) can trivially downgrade you to plaintext

  138. Kev

    jonasw: They have to do it from the get-go, though.

  139. jonasw

    Kev, in your case, yes

  140. Kev

    Well, depending on exactly what's implemented :)

  141. Kev

    Right.

  142. Guus

    Made it just in time 🙂

  143. MattJ

    The question is, who else did? :)

  144. Guus

    You, for one. 🙂

  145. MattJ

    nyco, around?

  146. MattJ

    ralphm seems to have been popping in and out, I think he's on mobile

  147. Guus

    nyco mailed that he was not going to be here today.

  148. Guus

    Martin?

  149. MattJ

    Oh, missed that

  150. MattJ

    Oh, Gmail marked that thread as "Not important" and I overlooked it

  151. Guus

    that'll teach you to have such a filter activated on my name. 🙂

  152. Guus

    Shall we try this again next week?

  153. MattJ

    Yeah, I think so

  154. MattJ

    btw, Martin != Martin Hewitt

  155. Guus

    ah. didn't know, tx

  156. Guus

    ok, I'm off for a bit then. ttyl!

  157. MattJ

    See you :)

  158. Syndace

    So, I collected the OMEMO issues that I was able to filter from the short discussion earlier and wrote down my thoughts and ideas about them: https://hackmd.io/x70DAtLgSHqBzke49_vBrg I'd like to hear whether I grasped the core of the issues and whether my thoughts/ideas make any sense lol. Also please tell me what's missing and feel free to add your own ideas and comments.

  159. Dave Cridland

    Syndace, Are you aware of the MLS work under way in the IETF?

  160. Syndace

    Oh boy, I was not

  161. MattJ

    Dave Cridland, I'm assuming you are following it because you keep talking about it. How far is it from something everyone can implement?

  162. goffi

    Syndace: we can't send some data becose there is not full stanza encryption. I'm specially missing xml:lang like I've explained on the @standard list (and some other like message markup).

  163. jonasw

    Syndace, section 1, Idea #2 seems waaaay too complex

  164. Syndace

    jonasw, well but I think it would fix all issues at once

  165. Dave Cridland

    MattJ, Early days. But it's got some serious people working on it. You can actually get libraries and work with the current design, but it's approximately as scary as using TLS 1.3 draft 3 - chances of everything interopping in the future are pretty low.

  166. jonasw

    at the cost of UX, Syndace

  167. Dave Cridland

    MattJ, I'm not saying we should switch now. I'm just saying we should be prepared to write off OMEMO as an experiment in a year or so.

  168. Syndace

    jonasw: True

  169. Syndace

    Dave Cridland: Well great.

  170. jonasw

    solving bad UX by making it worse doesn’t seem good to me :)

  171. Syndace

    jonasw: Not worse I think

  172. MattJ

    Dave Cridland, I don't think that's a reason to not attempt to fix problems we have today in parallel

  173. MattJ

    If MLS is ready in a year, it's another 2-3 years before clients implement it widely enough

  174. Syndace

    jonasw: Do you think it's a super UX killer if you have to select which devices you want to exchange encrypted data with?

  175. MattJ

    meanwhile OMEMO is already quite popular today, even Pidgin supports it

  176. Dave Cridland

    MattJ, Well, I think we have an opportunity to show XMPP can be leading edge in this kind of thing.

  177. MattJ

    Sure, I'm up for that

  178. MattJ

    But the carousel of E2EE solutions is also a bit of a joke by now

  179. jonasw

    Syndace, yes, other systems have E2EE without such annoyinaces

  180. Dave Cridland

    MattJ, Yes, indeed.

  181. jonasw

    MattJ, no, pidgin *does not* support it.

  182. MattJ

    Let's not leave what we have working today at 90% for the next 1-3 years

  183. jonasw

    pidgin has two plugins both of which have their own quirks

  184. jonasw

    and it doesn’t even "have" those plugins as in they’re distributed, no, you have to get them from somewhere.

  185. MattJ

    jonasw, that worked against my argument, so I glossed over that (but yeah)

  186. jonasw

    Dave Cridland, MattJ, if we’re going to do another round in the E2EE protocol carousel (good term by the way), I’d suggest to tackle (nearly) full stanza encryption, to at least give it a benefit over staying with status quo

  187. Syndace

    jonasw: Is there a comparable system which allows multi-device e2ee where some devices do e2ee and some don't?

  188. jonasw

    Syndace, I don’t know, actually. but users won’t care about that

  189. jonasw

    in the end, you can have signal/whatsapp/whatever on botth your laptop and your phone and it works just fine -- even if on your laptop, you just view stuff which is on your phone via webrtc or something

  190. jonasw

    and competing against that with a complex selection dialog whenever you want to do e2ee, just nope

  191. Syndace

    jonasw: We could reduce it to "start private chat" which just starts the chat with all OMEMO-enabled devices and doesn't ask which devices should be included

  192. Syndace

    That way it would be a button click

  193. jonasw

    Syndace, and then we’re exactly where we are right now

  194. MattJ

    but not by default

  195. Dave Cridland

    jonasw, Sure. But given MLS also handles group chat (in fact, it *doesn't* handle anything but), that shoudl also provide impetus.

  196. jonasw

    Dave Cridland, OMEMO handles group chat today

  197. Syndace

    jonasw: Not really, because it's two seperate chats: One plaintext and one encrypted and the important thing: The user is aware that not all devices will get all messages

  198. goffi

    jonasw: is there a spec for that?

  199. Dave Cridland

    jonasw, Sort of. It handles groupchats by keying M times. MLS does it in one.

  200. jonasw

    goffi, dunno

  201. jonasw

    Dave Cridland, sorry, I have no idea

  202. jonasw

    I just know that it is possible

  203. Dave Cridland

    goffi, Good grief no. Did you think OMEMO was one of those *open* standards?

  204. goffi

    I know Conversation and Gajim handle it, but I think it's unofficial for now (i.e. no XEP)

  205. jonasw

    Syndace, "but other systems do have e2ee by default, why can’t you?"

  206. Syndace

    jonasw: Because we don't forve you to use it. You can though, by clicking this button right here

  207. Zash

    e2ee as an afterthought is going to be infinite pain whatever way you do it

  208. MattJ

    goffi, I'm not sure a spec is really needed

  209. jonasw

    Syndace, that doesn’t need any additional magic though. just *some* clients stepping back from the "OMEMO by default and everywhere" paradigm

  210. MattJ

    goffi, it's just MUC, you fetch the keys of all participants

  211. Syndace

    goffi, I think they just parse the MUC-style JID into the normal JID and then use OMEMO as usual

  212. jonasw

    Zash, WhatsApp supposedly managed to do it as an afterthought

  213. goffi

    Gajim told me last time I was in a MUC for testing, that it was working with member only rooms something like that (don't remember the message)

  214. Syndace

    jonasw: WhatsApp has one binary and forces usage of e2ee, would be easy with these preconditions

  215. goffi

    this should be explained in a XEP, even if it's short

  216. Syndace

    (or three binaries for each OS, whatever)

  217. Zash

    jonasw: supposedly. also they're one company who do all the clients

  218. Dave Cridland

    I suspect we'll need an HSTS equivalent for E2EE, certainly, and then move plaintext->opportunistic->e2ee-always

  219. Zash

    if clients were registered and known by the server then maybe

  220. goffi

    we are still blocking a bunch of XEP with OMEMO by default

  221. goffi

    as long as there is no full stanza encryption

  222. Dave Cridland

    Zash, I suspect client registration has ot become a Thing, anyway. There's a whole lot of optimizations we could do if we had that.

  223. goffi

    no more last message correction, no more in band real time text, no more, no more language detection, no more markup.

  224. Zash

    goffi: but we have the markdown-ish thing now /s

  225. jonasw

    goffi, but markup is in the <body/> nowadays anyways!!

  226. Dave Cridland

    goffi, Honestly, you needn't argue for full-stanza. ESessions had that a decade ago, I have no idea why OMEMO doesn't.

  227. Zash

    jonasw^5

  228. goffi

    Zash: don't tell me :'(

  229. jonasw

    Dave Cridland, possibly because time-to-market mattered more than doing things right?

  230. jonasw

    Zash, ^5

  231. Dave Cridland

    jonasw, Probably.

  232. jonasw

    Dave Cridland, I’d love if we could maybe not repeat the same mistake with whatever MLS integration will happen.

  233. Dave Cridland

    jonasw, Yes. I'd like to do that one right.

  234. Syndace

    Any info on how/whether MLS handles mixed plaintext-only clients and encrypting clients?

  235. jonasw

    Dave Cridland, Zash, if it ever gets less hot so I can think straight for more than 5 minutes in a row, I’m going to try to make some device identification thing in prosody. I need per-device passwords anyways.

  236. Syndace

    If we had device identification we could issue a simple warning: "If you send this message encrypted, only jid: phone and jid: laptop can receive the message. jid: web and jid: work can not."

  237. goffi

    I would argue that I rather use OX by default, I'm less interested in PFS that in mentioned features.

  238. Zash

    jonasw: I hear MattJ was working on that

  239. goffi

    and OX do full stanza encryption.

  240. MattJ

    jonasw, er, yeah, I have a mod_device_tracker

  241. MattJ

    I can publish it later today or tomorrow

  242. jonasw

    MattJ, I’m thinking about doing things in SASL

  243. pep.

    MattJ: tracker!! I knew it

  244. MattJ

    pep., it's ok, it asks for consent

  245. Zash

    jonasw: FWIW you could have per-device usernames too (or username+device), since they need have no relation to the bound JID

  246. jonasw

    Zash, I was more thinking of using the second identity one can pass in sasl

  247. jonasw

    if it’s a full JID with the bare JID equal to the one you’re authing for, the resource is the device ID

  248. Zash

    jonasw: modulo client support

  249. jonasw

    Zash, yeah...

  250. jonasw

    but do clients support getting forced to a different bare JID?

  251. Zash

    Sure

  252. jonasw

    I need to have tests for that.

  253. jonasw

    I’m not sure what aioxmpp would do

  254. Zash

    +1

  255. Zash

    Moar tests :)

  256. jonasw

    Zash, fun fact, I’ll probably go for device@username for per-device-passwords in IMAP :)

  257. Dave Cridland

    jonasw, See https://tools.ietf.org/html/draft-cridland-kitten-clientkey-00

  258. Zash

    jonasw: Have you noticed the client-uses-full-bind-something pidgin sends in the stream start?

  259. jonasw

    Zash, no

  260. Zash

    jonasw: Which had something to do with GTalk

  261. jonasw

    Dave Cridland, in my scenario, the devices would never learn the actual account password

  262. jonasw

    which is something I’d like to have

  263. jonasw

    actually, this is uspposed to be client certificates lite

  264. jonasw

    because client certs are hard

  265. Zash

    It could assign you a different hostname even, if you had whatever the hosted domain thing was

  266. jonasw

    Zash, crazy stuff

  267. jonasw

    need to keep that in mind; that might be useful to have to support legacy clients

  268. Zash

    sure

  269. Zash

    There are some modules in Prosody where the SASL username ends up differently from the JID localpart

  270. jonasw

    interesting

  271. Zash

    Some PHP forum one for example

  272. Zash

    One where you can have characters in the username that don't pass nodeprep

  273. Dave Cridland

    jonasw, Do a PIN-check on another session? But anyway, I'm happy to knock around idea on that with you.

  274. jonasw

    Dave Cridland, sounds good, but as I said .... it’s too hot here to think

  275. jonasw

    Dave Cridland, my idea was somewhat like this: - to add a new device, you generate an auth-code on your first device and enter that in the new device. it performs either something SASL2 or a variant of IBR to set a password for itself (the password is never shown to the user) - it will always authenticate with that password (somewhat like your CLIENT-KEY I suppose) - server can now track the device, which also means that a user can revoke any device at any time (e.g. lost or stolen)

  276. jonasw

    Dave Cridland, IIRC, client key had the issue that when the counter goes out-of-sync, you need to re-authenticate using the normal SASL mechanisms?

  277. Dave Cridland

    jonasw, Yes. It's designed as a "Remember this device" to go along with TOTP, and not exactly wehat you're after.

  278. jonasw

    mmmhm

  279. Dave Cridland

    jonasw, But that counter is intentional - anyone stealing the credential from the client cannot use it from another device if the original device is still in use - the counter gets out of sync and the server-side token is killed.

  280. jonasw

    I think CLIENT KEY is orthogonal to this, yeah. It could be used in a, as you say, "Remember this device" fashion to temporarily replace the SCRAM-with-device-password+TOTP flow if TOTP is used,.

  281. jonasw

    Dave Cridland, yupp, that’s good

  282. Dave Cridland

    jonasw, Oh, and it's designed such that you can't DoS the token by guesswork or stealing it from the server.

  283. jonasw

    it looked pretty solid when I looked at it back then, yeah

  284. jonasw

    but IANAC

  285. Dave Cridland

    C = Cryptographer?

  286. jonasw

    yes

  287. Dave Cridland

    Nor am I, but I play one on TV.

  288. jonasw

    :D

  289. pep.

    Syndace: in your pad, section 4 before idea1, you are confusing omemo and e2ee. e2ee doesn't require PFS

  290. Syndace

    pep.: Right.

  291. jonasw

    people suggesting: > In general, a short “yo, please deactivate OMEMO” plaintext answer should be enough. But this can be annoying if it happens too often! clearly have no idea at which level of technological literacy some people operate

  292. pep.

    Indeed

  293. jonasw

    Syndace, append to your list please "I re-installed Conversations and now I can’t access my history anymore", because people aren’t expecting PFS.

  294. Syndace

    jonasw: lol, yes I know that some people don't know what OMEMO is and how to disable it, come on don't take this so literal :D

  295. pep.

    Syndace: this is a real world issue :x

  296. Syndace

    jonasw: Better example of what to write?

  297. Andrew Nenakhov

    Our take on encrypted conversations that we plan to implement soon is to have separate encrypted and decrypted chats. Like telegram's secret chats.

  298. vanitasvitae

    Syndace: after having implemented OX (OpenPGP for XMPP) I think one huge improvement that OX is having over OMEMO is the ability to encrypt arbitrary extension elements. I think full stanza encryption is rather unrealistic for xmpp, but you can put all the sensitive data into an encrypted container and be done :)

  299. vanitasvitae

    We should really port this to OMEMO / put it in a standalone XEP and let OX and OMEMO depend on it

  300. Andrew Nenakhov

    Telegram also solves multidevice e2ee quite simply: secret chats are one on one device only.

  301. Syndace

    Andrew Nenakhov: Interesting, who is "our"?

  302. Andrew Nenakhov

    Xabber.

  303. vanitasvitae

    Andrew Nenakhov: the single device part is one of the things that keep me from using secret chats :/

  304. Andrew Nenakhov

    I also hate pfs obsession

  305. lovetox

    nobody has a pfs obsession

  306. lovetox

    its just what we have

  307. Andrew Nenakhov

    Publish a pgp key, share it to all devices, have your history everywhere.

  308. vanitasvitae

    Moxie does :D

  309. lovetox

    we cant just snip our fingers and invent super secure encryption protocols

  310. lovetox

    Andrew Nenakhov, yes you can do that with OX

  311. Andrew Nenakhov

    If you care that much about privacy, don't lose that key.

  312. lovetox

    Omemo was just there first, and its easier to implement

  313. Andrew Nenakhov

    > Moxie does :D A lot of other guys do too. Constantly bombard our issue trackers with demands.

  314. vanitasvitae

    :D I have heard of that infamous bug report ;)

  315. Syndace

    What about a mechanism to synchronize local history from another device? xD

  316. Andrew Nenakhov

    :-D

  317. Andrew Nenakhov

    That bug report is, yes, epic

  318. MattJ

    Syndace, that has been discussed in the past - the protocol is already there - XEP-0313 could work between clients just as it does between client and server

  319. Andrew Nenakhov

    Btw, why would people want "full stanza encryption"?

  320. Andrew Nenakhov

    If you encrypt whom you address stanza, it'll never be delivered 😂

  321. vanitasvitae

    At FOSDEM I heard the idea of establishing encrypted XML streams between clients :D

  322. lovetox

    obviously not the top element..

  323. MattJ

    vanitasvitae, that has also been discussed and done before

  324. labdsf

    MattJ: gajim recently removed this feature

  325. Syndace

    MattJ: Wondering how serious to take this idea

  326. Andrew Nenakhov

    What is there to encrypt besides top element 😂😂😂

  327. lovetox

    every child element?

  328. Syndace

    Would be pretty cool to have history even on fresh OMEMO devices

  329. MattJ

    Andrew Nenakhov, OOB element for file transfers, for example

  330. Andrew Nenakhov

    > Would be pretty cool to have history even on fresh OMEMO devices As I understand OMEMO, this wish goes against all it stands for. :-/

  331. Syndace

    Not if you can sync the local history from your other devices or your chat partners

  332. labdsf

    Andrew Nenakhov: Signal has synchronization between start vices

  333. labdsf

    Between devices*

  334. lovetox

    it can provide this, because it does not have to deal with different clients

  335. Syndace

    lovetox: Doesn't sound very hard to throw the serialized XML into OMEMO instead of a plaintext message for nearly-full-stanza-encryption

  336. lovetox

    this would mean making a protocol for exchanging databases

  337. lovetox

    who said full stanza encryption is hard? as some people point out this exists probably for a decade in xmpp

  338. Syndace

    What about substanzas that are meant for the server (like hints)?

  339. lovetox

    you obviously cant encrypt them because then they are useless

  340. Syndace

    I was wondering whether to treat them in a special way or to just ignore them

  341. lovetox

    with full stanza encryption we dont mean full like everything

  342. lovetox

    we mean all data that are not necessary for the server to function

  343. Andrew Nenakhov

    > Andrew Nenakhov: Signal has synchronization between start vices Doing that is definitely possible in a number of ways, every single of them denying all advantages their protocol has over PGP.

  344. Andrew Nenakhov

    You can sync history directly between devices. You can share keys and download and decipher messages from server archive

  345. Andrew Nenakhov

    But why bother using omemo if you plan to do that?

  346. Syndace

    signal uses omemo aswell (basically)

  347. Syndace

    why do you think they do it that way? because its convenient probably

  348. vanitasvitae

    If you do the backup exchange using OMEMO, you dont lose any advantages of OMEMO

  349. vanitasvitae

    if you do it via OpenPGP however, your whole history is on the server twice, once OMEMO encrypted and once via OpenPGP. In that case you lost pfs due to the OpenPGP copy which can in theory be decrypted in the future.

  350. vanitasvitae

    So for backup exchange you'd want to generate a single-use key.

  351. Andrew Nenakhov

    Why twice? One openpgp is enough.

  352. Andrew Nenakhov

    Backup exchange is also bad ux by the way.

  353. Andrew Nenakhov

    You want your messages everywhere at once.

  354. Andrew Nenakhov

    So in the end if you want security and convenience , just run your own server.

  355. vanitasvitae

    Then you need OpenPGP and you cannot have pfs

  356. Andrew Nenakhov

    Because in xmpp the only ones who are affected by e2ee are server operators.

  357. goffi

    ho Gajim removed direct stream encryption? What a pity, I find it the most secure way if you have something really sensitive to say

  358. goffi

    I guess same effect can be achieved with XEP-0396 nowaday

  359. lovetox

    Gajim never head direct stream encryption

  360. lovetox

    and why is it a pity if no client supported that?

  361. Link Mauve

    Hi, what should happen with MAM when a client did a <query/> without specifying a @queryid? Should the <result/>s also not contain one?

  362. Link Mauve

    So far I made it required in my parser but I guess it should be optional due to that.

  363. lovetox

    yes Link Mauve correct

  364. lovetox

    dont add a query element if the client doesnt set one

  365. lovetox

    makes no sense, because its a identifier for the client

  366. lovetox

    if it set none it doesnt need it

  367. Link Mauve

    Yup.

  368. Link Mauve

    Wut, the changelog of RSM says that the <index/> element has been removed, but it is still present thrice in the text (including twice in examples).

  369. jonasw

    maybe a different <index/> element? *hope*

  370. flow

    Link Mauve, attribute vs element?

  371. Link Mauve

    Nope, I checked already.

  372. Link Mauve

    flow, nope.

  373. flow

    ahh right, the elemnt still appears in the text

  374. Link Mauve

    Hmm, I think I should split my RSM element into query and result, that would make it a lot easier to understand what’s going on.

  375. flow

    Who is 'vm'?

  376. Link Mauve

    Someone from before my time, I guess.

  377. jonasw

    This one just came up in another room: https://xmpp.org/extensions/xep-0238.html

  378. jonasw

    do we maybe want to deprecate/obsolete/reject that?

  379. jonasw

    it seems to be ... way out of date

  380. jonasw

    and there doesn’t seem to be any interest in refining it

  381. Link Mauve

    jonasw, +1, although in the past we’ve considered deferred as a tombstone.

  382. Link Mauve

    But I’m still +1 to explicitly obsolete it.

  383. jonasw

    yeah, deferred isn’t explicit enough

  384. Link Mauve

    And I think we shouldn’t let XEPs stay in limbo like that forever.

  385. Yagiza

    If I implement deffered XEP in my software, may it change its status?

  386. Link Mauve

    Yagiza, you should send an email to standards@ to explain why imo, then someone will most likely revisit it.

  387. Zash

    Yagiza: Possibly, especially if you write to the standards@ list or the author with feedback

  388. jonasw

    Yagiza, there are two types of deferred XEPs (and you cannot tell them apart by the status): those which are abandoned, and those which are "good enough" and which are silently implemented everywhere

  389. jonasw

    Yagiza, so if you implement a deferred XEP, post any feedback you have to standards@ (even if it’s just "implemented it, it solves my issue X"), that might trigger advancement to Draft

  390. Link Mauve

    You may also send a change, anything, something you found missing/misformulated/anything in the text, which would automatically put it back to Experimental.

  391. Zash

    jonasw: I'd say there's some gray area inbetween, where the author just happens to be busy with other stuff

  392. jonasw

    Zash, I’d call that "abandoned", even though that’s harsh

  393. Link Mauve

    Zash, can confirm. :-°

  394. Zash

    jonasw: sounds intentional then, which it might not be

  395. jonasw

    hm, ok

  396. Yagiza

    I just want to try implementing XEP-0371 in my client as a good solution for file transfer.

  397. jonasw

    Yagiza, uh... in combination with XEP-0234?

  398. Yagiza

    Yes, of course

  399. Yagiza

    Also, its implementation may increase chances of successful Jingle RTP session.

  400. Link Mauve

    This one is an instance of the good kind of deferred XEP.

  401. Yagiza

    Link Mauve, so, if I implement it, it may make things better?

  402. jonasw

    yes

  403. Yagiza

    Ok. Sounds good.

  404. Zash

    Higher chance of things becoming better if you send feedback to standards :)

  405. Link Mauve

    In pubsub#event, I see @node being defined on item, but I don’t see it used anywhere in the XEP.

  406. Link Mauve

    What and where could it be used for?

  407. Zash

    Section?

  408. Link Mauve

    XML Schema.

  409. Zash

    https://xmpp.org/extensions/xep-0060.html#example-2 that @node ?

  410. Link Mauve

    This is on items, not on item.

  411. Zash

    Wait where do you see a node attr?

  412. Link Mauve

    Line 7007 of the XML file in the xeps repository.

  413. Zash

    Which object? :)

  414. Link Mauve

    What do you mean?

  415. jonasw

    https://github.com/xsf/xeps/blob/master/xep-0060.xml#L7001

  416. jonasw

    Link Mauve, might’ve been a mistake

  417. jonasw

    node doesn’t make sense on item

  418. Zash

    semi-serious reference to git object

  419. jonasw

    hm, unless items from different nodes are batched in a single event

  420. Link Mauve

    I’ve never seen that done.

  421. Link Mauve

    But everytime I read this XEP, I learn new things.

  422. jonasw

    everybody seems to say that about '60

  423. Link Mauve

    And items@ver isn’t specified in the schema. :|

  424. jonasw

    lovely

  425. Zash

    https://xmpp.org/extensions/attic/jep-0060-1.7.html#schemas-event https://xmpp.org/extensions/attic/jep-0060-1.8.html#schemas-event

  426. Link Mauve

    Oh no, this is commented in the XML file.

  427. jonasw

    Link Mauve, where?

  428. jonasw

    ah nevermind

  429. Link Mauve

    Is it actually possible to have a <{pubsub#event}items/> with neither <item/>s nor <retract/>s inside?

  430. Yagiza

    Zash, that's implied

  431. Link Mauve

    “19:09:00 vanitasvitae> At FOSDEM I heard the idea of establishing encrypted XML streams between clients :D”, yes, XEP-0246, XEP-0247 and XTLS. ^^

  432. vanitasvitae

    Link Mauve: yeah I think we talked about it right?

  433. Link Mauve

    Yes, on the last day, outside K.

  434. vanitasvitae

    Right :D