XSF Discussion - 2020-06-01


  1. Guus

    what's the better client on Mac these days?

  2. Andrzej

    on macOS I'm using BeagleIM but I'm developer of BeagleIM so I may be biased

  3. Kev

    I use Swift, obviously ;)

  4. Kev

    Although I'm using 5.0previews rather than 4.0.

  5. Guus

    I'm starting to see the flaw in my approach.

  6. mathieui

    Guus, :D

  7. Zash

    Why doesn't xep-0084 use "current" or something as item id for the metadata node?

  8. Yagiza

    Zash, I guess authors just forgot about it.

  9. Yagiza

    If I adopted a XEP and now is an author of, may I commit my changes directly to XEP repo, or I must do it via PRs?

  10. Andrzej

    Zash: I think that section 7.1. will answer that https://xmpp.org/extensions/xep-0084.html#impl-resources

  11. Zash

    Ugh

  12. Kev

    Yagiza: PRs

  13. Yagiza

    Kev, IC, thanx.

  14. Yagiza

    Kev, once I publish a PR for a deffered XEP, should I change its status back to experimental in that PR?

  15. Kev

    Maybe submit the PR without it, and ask what the Editors would like you to do.

  16. Kev

    I don't know if jonas’ normally asks authors to do that bump, or not.

  17. Yagiza

    Kev, so, I have to ask him first?

  18. Kev

    I would. But if you don't do what he wants, he'll let you know anyway :)

  19. jonas’

    Yagiza, feel free to change back to Experimental in the same commit you add the <revision/> lbock

  20. Kev

    There we go :)

  21. jonas’

    if you don’t add a <revision/> block but want the Editors to do that, then please also don’t change the status

  22. Yagiza

    jonas’, ok, thanx!

  23. Yagiza

    I wonder...

  24. Yagiza

    If I receive a <message/> with <attention/> element and it with an encrypted <body/> element, which I failed to decrypt, what client shoftware should display?

  25. Zash

    🔒️💔️🤷‍♀️️

  26. pep.

    OMEMO < 0.4?

  27. Yagiza

    Should it display Attention, notifying user, that it had message text, which it failed to decrypt, or just notify user about it failed failed to decrypt message, without trying to attract his attention?

  28. pep.

    What do you do if you receive LMC and fail to encrypt body?

  29. Yagiza

    pep., right now I'm working on OMEMO v5.0, but I'm asking in general.

  30. pep.

    What do you do if you receive LMC and fail to decrypt body?

  31. Zash

    What do you do if something fails for any reason?

  32. Yagiza

    pep., LMC is not supported right now.

  33. Yagiza

    Zash, it depends.

  34. pep.

    Replace "LMC" with anything that you support that's not stuffed in <body/>

  35. vanitasvitae

    Yagiza: I'd argue that with OMEMO:1 the <attention> would probably also be part of the <encrypted> element, no?

  36. Yagiza

    vanitasvitae, I don't think so. <attention/> element contains no sensitive information to encrypt it.

  37. vanitasvitae

    But I admit that such error cases are not yet well covered.

  38. vanitasvitae

    Mostly due to lack of experience.

  39. vanitasvitae

    Well, having it plain leaks that there is an attention in the first place

  40. pep.

    this ^

  41. Yagiza

    So, let's suppose we use some type of old encryption, which do not support SCE.

  42. vanitasvitae

    Yeah in that case there is no way to not leak the exiatence of the <attention>

  43. pep.

    There is a way, just don't send it :P

  44. vanitasvitae

    Haha :D

  45. Yagiza

    Encrypting <attention/> element or not is up to implementation right now, 'cause it is not regulated by any XEP.

  46. vanitasvitae

    Yeah, sce should be more precise in that

  47. Yagiza

    So, let's get back to the initial question: what to do, if only <body/> was encrypted and we failed to decrypt it?

  48. pep.

    In poezio I'm filtering out everything that doesn't go in <body/> when doing OMEMO, because of this limitation

  49. vanitasvitae

    I'd say simply encrypt anything that doesnt need to be read by the server.

  50. vanitasvitae

    (As a rule of thumb)

  51. vanitasvitae

    > So, let's get back to the initial question: what to do, if only <body/> was encrypted and we failed to decrypt it? I'd say there is no ideal way to recover :(

  52. vanitasvitae

    Probably discard the attention?

  53. pep.

    Yagiza, tell both to your user? "Somebody is requiring your attention but we don't know what for"

  54. vanitasvitae

    Or that

  55. pep.

    I don't know what poezio does. "Attention" is not something I see everyday :x

  56. Zash

    print \a ?

  57. pep.

    Zash, in the case it can't decrypt body?

  58. Zash

    Dunno?

  59. Yagiza

    pep., eyeCU is a GUI cliant, so it does a lot of annoying things to attract user's attention. That's why it's critical what to do in such case.

  60. Zash

    Show what you know? "Couldn't decrypt message. Extra stuff: attention"

  61. pep.

    Yagiza, it's critical to annoy the user more? :P

  62. Yagiza

    pep., it's critical to annoy user with suspicious attempt to attract his attention, or not.

  63. dwd

    Anyone know where the slixmpp devs hang out? Poezio MUC perhaps?

  64. pep.

    Poezio MUC works, you might have more people there, but otherwise it's xmpp:slixmpp@muc.poez.io?join

  65. pep.

    or jdev

  66. lovetox

    Yagiza, simple, you display the omemo fallback message like you always do when you cant decrypt it

  67. lovetox

    and then additionally run the attention code, whatever that is

  68. lovetox

    i dont know why you are spending much more thought on that

  69. lovetox

    and of course with omemo:1 it should be encrypted

  70. lovetox

    you should not get into the fallacy to decide yourself what stuff seems important to *you* and needs to be encrypted

  71. Yagiza

    lovetox, well... when I run Attention code, do I have to display "Failed to decrypt" fallback message, or just no message at all?

  72. lovetox

    full stanza encryption means, encrypt the full stanza, except stuff that is added for partys that cannot decrypt (like the server)

  73. lovetox

    Yagiza, i remember you argued the other day

  74. lovetox

    to have a fallback body

  75. lovetox

    and now you thing about not displaying it?!

  76. lovetox

    and now you think about not displaying it?!

  77. Yagiza

    lovetox, "fallback body" and "fallback message" are different things.

  78. lovetox

    how are they different?

  79. lovetox

    inside the fallback body is the fallback message

  80. lovetox

    except you mean something different

  81. lovetox

    but the question really is, why would you want to treat this non-decryptable message differently because it has an attention attached

  82. lovetox

    do whatever you do when a message fails to decrypt without attention

  83. Yagiza

    "fallback body" is a <body/> element of stanza with <encrypted/> element, to be shown by clients, which know nothing about encryption. "Decryption failure fallback message" - is a message, which client, which supports encryption displays, when it failed do decrypt encrypted content.

  84. jonas’

    lovetox, though, maybe <attention/> is important for the server? thinking push & stuff

  85. pep.

    Maybe there should be a systematic study of all new XEPs wrt. SCE. That is, should they be in or out :x

  86. pep.

    But what about the 400 previous XEPs..

  87. Zash

    Didn't we start an E2EE WG?

  88. pep.

    I don't think going through all previous XEPs is doable anyway. I think general definitions like vanitasvitae or lovetox gave here are good, with maybe a few explicit exceptions / examples

  89. Zash

    When I looked at MAM, Carbons and CSI code recently, I started with the ones in the latest compliance suite.

  90. Zash

    + >= Draft maybe

  91. moparisthebest

    > "Decryption failure fallback message" - is a message, which client, which supports encryption displays, when it failed do decrypt encrypted content.

  92. moparisthebest

    the SENDING client gets to decide this????

  93. Zash

    Planning for failure eh?

  94. moparisthebest

    my knee-jerk reaction is that is wrong and maybe exploitable, but I'll have to think about it harder

  95. pep.

    I don't understand the sentence enough to react this way :x

  96. lovetox

    Yagiza, but for your question its irrelevant if fallback body, or your custom failure message

  97. lovetox

    moparisthebest, i think you misunderstanding something

  98. moparisthebest

    very likely, the only context I have is that right there

  99. lovetox

    if you mean the server could manipulate the encrypted content so its not decryptable anymore, then exchange the fallback body with a message of his choice

  100. lovetox

    yes thats possible

  101. lovetox

    but 1. the message would show as unencrypted

  102. Yagiza

    lovetox, for me that's important. In this case I have to display decryption failure message. And I want to know, if I have to display it as Attention message, or should I display Attention with no message, and display decryption failure message as a separate message (not Attention).

  103. lovetox

    2. only clients that dont support encryption at all, should use the fallback body

  104. lovetox

    let me rephrase this

  105. lovetox

    2. only client that are legacy and not updated anymore use the fallback body

  106. lovetox

    every maintained client should depend on the <eme> attribute, and display his own failure messages, not depending on the fallback body

  107. Yagiza

    moparisthebest, why sending? Sending client cannot know if receiving client will successfully decrypt message content or something will go wrong.

  108. lovetox

    but yeah thats definitly an attack vector against clients that simply always display fallback body without an additional hint

  109. lovetox

    of course Yagiza, the sending client can always know when you cant decrypt the messge

  110. lovetox

    because the sending client can simply encrypt it wrong

  111. lovetox

    and for a server its even more simple

  112. lovetox

    just cut some bytes of the encrypted payload

  113. lovetox

    and i can make sure you cannot decrypt it anymore

  114. lovetox

    then i add my own body

  115. lovetox

    you should never trust the fallback body

  116. Yagiza

    lovetox, yes. So, sending client MUST NOT decide, which message will be displayed in case of failure. Only receiving client should display correct message to notify user about an error.

  117. lovetox

    fallback body is for legacy clients

  118. lovetox

    pidgin and stuff

  119. lovetox

    i just thought about what i said

  120. lovetox

    this is no attack vector at all

  121. lovetox

    the server can send the client messages all day

  122. lovetox

    manipulating an encrypted message into non-decryptable is only more work

  123. moparisthebest

    But why add another payload to worry about, if a client capable of decryption can't decrypt something, it should display it's own message in it's own language, not something the sending client said, no?

  124. lovetox

    we do that moparisthebest

  125. lovetox

    we add a message for legacy clients

  126. lovetox

    that dont know anything about encryption

  127. Neustradamus

    https://medium.com/tenable-techblog/turning-signal-app-into-a-coarse-tracking-device-643eb4298447