XSF Discussion - 2019-02-06


  1. ralphm

    I'm having this discussion on E2E encryption with michael on Twitter, but what he describes about key exchange sounds like a bug. https://twitter.com/mickael/status/1093128804728557570

  2. ralphm

    mickael

  3. ralphm

    This isn't inherent to the protocol, is it?

  4. jonas’

    does it use multi-item PEP?

  5. dwd

    No, the key exchange stuff is pretty rubbish.

  6. Zash

    PEP and MAM on login adds a bit, not sure how significant it is

  7. dwd

    This isn't helped by the key service really needing more smarts than just a big PEP blob anyway.

  8. Zash

    Multi-item was less commonly supported by servers before, so would have been a pain to deploy if it was required

  9. ralphm

    dwd: but is it as bad as mickael describes?

  10. pep.

    ralphm, bundles are only needed on session init

  11. pep.

    So they get fetched at that time

  12. pep.

    But session init doesn't happen often

  13. dwd

    ralphm, Well, I don't know about how loaded blatting out a big blob actually makes a server.

  14. ralphm

    pep.: Yeah, that was my thought, too.

  15. jonas’

    I think the increased message size in MAM is probably more worrisome

  16. pep.

    Well that's an issue with e2ee at all right?

  17. jonas’

    that affects bandwidths (memory, disk and network) and disk storage

  18. jonas’

    pep., yes, that’s kind of the point

  19. ralphm

    jonas’: well, I am not surprised about encrypted stuff being bigger in general

  20. pep.

    k

  21. Kev

    Depends if it's hitting disk for PEP each time or something, I imagine.

  22. Zash

    The real problem is that everything is hitting the disk for way more stanzas now than in the past

  23. dwd

    Kev, And if not, the memory pressure is probably greatly increased.

  24. Kev

    dwd: Quite.

  25. ralphm

    But this isn't a property of which protocol we use for e2e, is it?

  26. Kev

    Message size? No. Key exchange details? Yes.

  27. ralphm

    The increase in MAM storage, I mean.

  28. Kev

    (Or ln -s No Not\ Entirely)

  29. ralphm

    Right, if the key exchange is suboptimal, then that's a thing we can look into. I'm surprised that mickael says the impact would be 'huge'.

  30. dwd

    ralphm, Yes, it can be. MLS, for instance, would be hugely more efficient in bandwidth terms where OMEMO is used within MUCs, for example.

  31. dwd

    ralphm, But I would personally just treat OMEMO as the experiment it is, and await MLS patiently, and do things properly then.

  32. ralphm

    I don't think we are talking about group chats at this point, though.

  33. pep.

    If you don't have to reencrypt for each device, certainly yes :)

  34. goffi

    dwd: I forgot to ask you about that by the way, is there any progress and where can we follow them?

  35. pep.

    ralphm, for 1:1 you still encrypt for each of your recipient's devices

  36. goffi

    (mls)

  37. pep.

    With OMEMO

  38. dwd

    goffi, MLS has an IETF working group, and is taking time - lots of effort in the low-level crypto.

  39. ralphm

    pep.: sure, but what's this about 100s of PreKeys?

  40. dwd

    ralphm, That's a property of most of these algorithms, including MLS. Each device must upload a bunch of prekeys, and a new session takes one.

  41. pep.

    I'm not exactly sure about prekeys, maybe Syndace can chime in, and why we need 100. I guess that's when people want to start a session with you, and how often you need to renew them

  42. pep.

    (renew them > the prekeys)

  43. Zash

    What happens if two sessions are started using the same prekey?

  44. dwd

    ralphm, My sketch of a XEP for MLS, for instance, says that servers provide a keying service and hand out a single prekey for each device on demand.

  45. Kev

    Although even 'having 100 prekeys' doesn't necessitate our current mechanism.

  46. Kev

    Right, that'd do it.

  47. dwd

    Zash, Nothing - in principle. But it makes the cryptanalysis much harder.

  48. pep.

    Zash, that happens regularly, because we don't have reliable message delivery. So some clients will use the same prekey until they get an ACK from the other side

  49. ralphm

    (for reference, the WG is here: https://datatracker.ietf.org/wg/mls/)

  50. dwd

    ralphm, Thanks.

  51. dwd

    ralphm, Note that for each session, the requester will grab all the prekeys, pick a set (one from each device), and then use them. On successful session start, the called device then removes the set from the prekey blob and re-uploads. This new bundle is then pulled by each device.

  52. Daniel

    > ralphm, My sketch of a XEP for MLS, for instance, says that servers provide a keying service and hand out a single prekey for each device on demand. This is probably the 'proper' solution. For omemo we deliberately decided against an omemo component in favor of faster adoption. But learning about the limitations of PEP and how fast we can role out components if we need to (http upload) this is one of the regrettable features of omemo.

  53. Daniel

    Or not that much regrettable but rather 'lessons learned'

  54. dwd

    Daniel, For sure - and I would note that this is a fine design if treated as an experiment.

  55. ralphm

    dwd: sure, but how often does one have a new session? That's still not a common thing, is it?

  56. dwd

    ralphm, Every new conversation.

  57. pep.

    dwd, really?

  58. pep.

    Is it some security thing I don't understand, or is it a limitation, or?

  59. Zash

    pep.: What thing?

  60. pep.

    what what

  61. dwd

    pep., I would think so. The ratcheting means you can re-use a session for lengthy periods, but you'd need to store a fair chunk of cryptographically-sensitive state, so I'd think you'd discard that after a period of inactivity in a conversation and start anew later.

  62. ralphm

    Daniel: when do sessions expire in Conversations?

  63. dwd

    pep., That said, I've not looked at what OMEMO implementations actually do. The spec more or less says "use libsignal", so it's hard to tell.

  64. pep.

    I would assume in OMEMO session initiation is not something that happens often, judging by how easy it is to lose messages when negociating a new one. If the other side starts a new session and drops the old one, and I don't, I'll send a message and they won't be able to read it.

  65. Zash

    pep.: Cryptosystems usually need something like a 3-way handshake. As I understand it, prekeys are the first step in that. (Is that the "what"?)

  66. Daniel

    ralphm: they don't

  67. ralphm

    Daniel: so in Conversations, a session between two users doesn't change keys, until you add/remove devices, or explicitly want to use a new key?

  68. Daniel

    A session is something that exists between devices. So adding a new device will create an additional session and not change something about the existing ones

  69. Daniel

    But the ratchet for each session is of course moved forward on every received message

  70. ralphm

    right, I'm trying to understand what the actual traffic behaviour is, with respect to our current key exchange, and whether this is worse in some implementations than others

  71. Syndace

    Ugh not reading for a day and 500 messages with a lot about OMEMO >.<

  72. Daniel

    ralphm: regarding the Twitter?

  73. ralphm

    yeah

  74. Zash

    Syndace: Enjoy your FOMO :)

  75. pep.

    Syndace, stop slacking off!

  76. Daniel

    This is I assume about the prekeys

  77. ralphm

    I Slack off all the time, I call it market research, or work, depending who's asking.

  78. Seve

    Haha

  79. pep.

    :D

  80. Daniel

    So on login due to broken pep a client doesn't know if the prekey list on the server is up to date and will update it

  81. Daniel

    Which as I just mentioned on Twitter is something one could probably fix now that pep isn't broken

  82. ralphm

    so without session resumption (XMPP session, not OMEMO), this might be often

  83. Daniel

    That often

  84. Daniel

    ralphm: yes

  85. Ge0rG

    I wonder why people insist on PFS, deniability and per-device keys. If you just have a per-account key that is shared between your devices, you can have such a simple e2ee scheme.

  86. Zash

    Ge0rG: Because PFS has more marketing behind it and looks better for ültraparanoid cryptonerds :)

  87. moparisthebest

    then why wasn't xep-27 widely adopted/used ?

  88. Zash

    OpenPGP is Hard and '27 is awkward

  89. moparisthebest

    it's just a different use-case, PFS has valuable properties, it also has downsides

  90. Zash

    It's got the word "Perfect" in it!!!1

  91. Ge0rG

    *cough* https://op-co.de/tmp/SEX.html *cough*

  92. Zash

    moparisthebest: Also beacuse crypto wasn't hip and cool and buzzword-compatible enough back then

  93. moparisthebest

    plus it doesn't have signing or replay prevention

  94. Zash

    Snowden and Facebook scandals does a lot of marketing for magic crypto dust and these last years seem to have been a good time to push this stuff

  95. Zash

    moparisthebest: As I said, '27 is awkward.

  96. dwd

    moparisthebest, eSessions ticked most boxes, but wasn't ever deployed either.

  97. Zash

    Gajim had it (removed now?)

  98. dwd

    moparisthebest, But also, there's RFC 3923, of course.

  99. dwd

    Zash, Yes, indeed. MattJ and I used to fiddle constantly to stop it encrypting as I recall.

  100. dwd notes that even RFC 3923 had full-stanza encryption.

  101. Ge0rG

    It looks like xmpp.org is flapping ipv6 again.

  102. Ge0rG

    IPv4 is also affected.

  103. Ge0rG

    Sometimes it works, sometimes it fails.

  104. jonas’

    my monitoring agrees

  105. Ge0rG

    But now also my IRCnet fails, so maybe it's a larger issue somewhere in Yurop

  106. edhelas

    the Brexit has strarted

  107. jonas’

    bad network weather

  108. Zash

    Dun dun duuuun

  109. dwd

    Council meeting about to start over there: --> council@muc.xmpp.org

  110. jonas’

    /correct Council meeting about to start over there: --> xmpp:council@muc.xmpp.org?join

  111. Zash

    /sudo -u dwd /correct ...

  112. jonas’

    I can haz sudo XEP?

  113. Zash

    SASL sorta has it already actually

  114. jonas’

    yeah, without reconnecting pls

  115. Zash

    authz vs authn something something

  116. Zash

    But yeah, overwriting other peoples messages ... might have its uses

  117. Zash

    Tho attaching or somesuch might be fine for most of them

  118. flow

    So fun question, is the 'by' attribute of stanza errors (RFC 6120 § 8.3.2) guaranteed to be an JID, or can it be an arbitrary string?

  119. flow

    I am missing the "the JID of" before "the entity" in the paragraph specifying it, just like it is done everywhere else

  120. Zash

    flow: Is there any text that suggests that "entity" is equivalent to JID?

  121. flow

    Zash, yes and no, guess it depends on the type of the entity

  122. Ge0rG

    flow: you don't want to enforce this in the type system, do you?

  123. Zash

    I thought it was a JID

  124. Ge0rG

    I'm really excited to get my client crashed by type system exceptions caused by remote entities!

  125. Zash

    Maybe(JID | String)

  126. Zash

    Have fun

  127. Ge0rG

    Someone is going to mess up my bookmarks with a robot face MUC and I'll end up in an endless connect loop.

  128. rion

    It seems there is an error in https://xmpp.org/extensions/xep-0261.html examples 9, 10. New SID has to be different for second stream but it has to be the same for for <transport> and <open>

  129. MattJ

    rion, can you post that to the standards@ list?

  130. rion

    I'll send a pull request with fix

  131. lovetox

    rion, do you mean example 10 has the wrong sid

  132. rion

    lovetox: yes

  133. lovetox

    should be bt8a71h6 instead

  134. lovetox

    yeah seems like a copy/paste error

  135. rion

    https://github.com/xsf/xeps/pull/755

  136. Link Mauve

    Daniel, could you add IPv6 support to conference.siacs.eu please?

  137. Link Mauve

    I don’t currently have an IPv4 on my server, and it prevents me from joining.

  138. Daniel

    Link Mauve: it's on the todo list

  139. Link Mauve

    Great, thanks. :)

  140. Link Mauve

    Kev, could you do the same with rooms.swift.im please?

  141. rion

    another error https://xmpp.org/extensions/xep-0167.html example 50. wrong action.

  142. pep.

    rion, please PR :)

  143. rion

    https://github.com/xsf/xeps/pull/756

  144. pep.

    thanks o/

  145. rion

    xep-0167 example 48 probably should include some candidates to <transport> or at least refer to consequent transport-info actions for transport negotiation.