XSF Discussion - 2019-01-05

  1. prezident

    hi, i am having a question regarding the correct use of starttls. i noticed that sleekxmpp just copies the response from the server, and the servers seem to accept that. this leads to the following: s: <starttls><required/></starttls> c: <starttls><required/></starttls> s: <proceed> is this the correct usage, or should child elements be disallowed at this stage? current implementation also allows sending of arbitrary elements like <starttls><penis-required/></starttls>...

  2. Zash

    Lol

  3. Zash

    prezident: You're supposed to ignore everything you don't understand.

  4. Link Mauve

    prezident, most implementations don’t reject invalid attributes or children, but you shouldn’t rely on that.

  5. prezident

    well, the rfc only states <starttls/> on client side

  6. prezident

    does that leave room for interpretation?

  7. prezident

    ejabberd does reject a lot of invalid xml, but not that for example

  8. prezident

    while it might not be helpful to just change current implementations i was just wondering how to interpret the rfc

  9. Link Mauve

    prezident, it’s definitely helpful to fix this library to only send what the RFC is asking.

  10. Link Mauve

    Note that SleekXMPP is kinda abandonned, and you should migrate to slixmpp at some point.

  11. prezident

    i am on the other side ;)

  12. Link Mauve

    You should tell your users to move to a non-abandonned library then. ^^

  13. prezident

    might be fixed already, who knows

  14. prezident

    the library wasnt my main focus really

  15. prezident

    i was more like wondering why no server rejects that

  16. Zash

    In the case of Prosody, it just doesn't really look that closely

  17. Zash

    Why would it? What does it matter?

  18. prezident

    i did not take into account that unknown child elements are not to be parsed

  19. prezident

    but at that stage, there really never are any children

  20. Kev

    Well, they're to be parsed, but unknown stuff is usually ignored.

  21. Kev

    Although technically that's meant to be stuff in unknown namespaces.

  22. Zash

    The code in question doesn't even inspect the payload. It gets triggered by the name and xmlns combo and does its thing

  23. Kev

    A server would be in its rights to reject that, because it's shoving stuff into a namespace it shouldn't be - but I'd be surprised to find many entities that did so, there's just no value.

  24. Half-Shot

    Hmm, I can't see prezident's messages.

  25. Link Mauve

    prezident, please write something.

  26. prezident

    kev: its a matter of how the parser is implemented

  27. Link Mauve

    Half-Shot, nothing should hide his messages from you, they are well-formed.

  28. prezident

    unicode thing?

  29. Zash

    message id attr?

  30. prezident

    miranda does not generate ids for groupchat messages

  31. prezident

    that could be it

  32. Kev

    prezident: All XML needs to be parsed, because malformed XML must be rejected.

  33. jonas’

    you also can’t really not-parse parts of the XML

  34. prezident

    kev: no i meant how you walk through the elements

  35. jonas’

    if you want to see what’s behind it

  36. Half-Shot

    Link Mauve: Okay, could also be a bug in xmpp.js :|

  37. Zash

    > <message ... id="07d1636f-0e7e-4700-a6b5-edb12ff2ee6d-50B"><body>unicode thing?</body></message>

  38. jonas’

    ah yes

  39. Zash

    Is that ... poezio adding the id?

  40. jonas’

    yes, poezio does that

  41. jonas’

    or rather, sli x ✎

  42. jonas’

    or rather, slixmpp ✏

  43. jonas’

    for reasons which are unclear to me

  44. prezident

    to identify the message...

  45. jonas’

    prezident, on *received* messages? ;-)

  46. jonas’

    that doesn’t make sense

  47. prezident

    yes, when reentering the room the client needs to know which messages it already showed to the user

  48. prezident

    which or what? whatever...

  49. Zash

    That doesn't make sense

  50. prezident

    it does

  51. jonas’

    I think we’re misunderstanding each other

  52. prezident

    or the client will save the same message again in its history

  53. jonas’

    slixmpp is adding IDs to messages it has received

  54. jonas’

    random IDs

  55. prezident

    and will display it one time more on every entering of the chatroom...

  56. jonas’

    since the IDs are added by the *receiving* client and independent of the content, there is no way this can be used for deduplication

  57. prezident

    oh sorry

  58. jonas’

    to make deduplication work, you have to add IDs on the sending client

  59. jonas’

    or the MUC service

  60. Zash

    Or somehow magically generate the same ID for the duplicate message again

  61. jonas’

    speaking of which, I’d like MUC services to add IDs to messages if the sending client didn’t.

  62. Zash

    Didn't we just add "server doesn't touch ids" as a feature?

  63. prezident

    jonas: mam adds an archive id to messages which fullfils this requirement

  64. jonas’

    Zash, yeah, but non-existent IDs aren’t IDs :)

  65. Link Mauve

    jonas’, +1, we should add that to MUC.

  66. jonas’

    prezident, requires the MUC to support MAM though, just for simple deduplication

  67. Zash

    Do it

  68. Zash

    Do it now

  69. prezident

    jonas’: of course a workaround only

  70. jonas’

    Zash, where do I get random IDs from again in prosody?

  71. Zash

    jonas’: util.id

  72. prezident

    but as this is only important for channels with history, isnt mam the right way to go anyway?

  73. jonas’

    you said that the other day, but I forgot

  74. jonas’

    thanks

  75. prezident

    "right" in the sense of best practice

  76. Zash

    jonas’: I'm wondering if the "medium" one should be closer to uuidv4 in entropy

  77. jonas’

    Zash, sounds reasonable

  78. jonas’

    Zash, https://paste.debian.net/hidden/69c1e82e/ ;-)

  79. Zash

    :)

  80. jonas’

    ah, it ate the tabs again

  81. Half-Shot

    Ah, so I couldn't see `prezidents` message because the ID wasn't there/ wasn't unique and the bridge dedupes messages across it's users using the ID.

  82. jonas’

    it should not do that with live messages

  83. jonas’

    only with history messages

  84. jonas’

    (if at all)

  85. Half-Shot

    I'll stick on debug logging to be sure, but I'm certain I've seen the same message arrive for all the participants connected via the bridge.

  86. Zash

    Well, of course, each participant gets a copy of the message.

  87. jonas’

    you could pick a primary participant whose message view you treat as authoritative

  88. Zash

    Skype bridge thing from back in the day had a magic user called "Skype" that was that primary user

  89. Zash

    Probably more correct to forward each message only to the occupant they're destined for

  90. jonas’

    that, too

  91. Zash

    Potential security issue if the MUC does things like security label based filtering.

  92. flow

    1

  93. lnj

    I was told to advertise this a bit, so also in this MUC: My MIX implementation in QXmpp has working parsing/serialization of most of what's in XEP-0369 and XEP-0405.

  94. lnj

    https://github.com/qxmpp-project/qxmpp/pull/174 https://github.com/qxmpp-project/qxmpp/pull/175 https://github.com/xsf/xeps/pull/730

  95. oli

    ‎lnj‎: nice!

  96. pep.

    TIL https://xmpp.org/extensions/xep-0247.html, which seems like a cool idea. It references http://xmpp.org/extensions/inbox/jingle-xtls.html though, as in it references an /inbox/ XEP. Any idea what happened about it? Why it was not accepted etc.

  97. Zash

    And todays XMPP archeology subject is ...

  98. Zash

    > We assume that all XMPP entities will have X.509 certificates hnnnm

  99. Zash

    I do wonder if something like SPK or SRP would work

  100. Zash

    Oh, it mentions SRP

  101. Zash

    Could do stuff with anonmous ciphers and sending some verifier in-band too.

  102. Zash

    pep.: I imagine the objection is that it's not perfect and you need to trust the server

  103. pep.

    As a server admin, I would very much like to benefit from plausible deniability, if that can ever be a thing :)

  104. Zash

    https://mail.jabber.org/pipermail/standards/2009-January/020877.html is the only relevant thing I find from 2009

  105. Zash

    pep.: "I could plausibly have MITMed your Jingle" ;)

  106. pep.

    I know..

  107. Zash

    Is there even encryption for Jingle today?

  108. Zash

    In use?

  109. pep.

    I assume XTLS was an attempt at that, maybe the only one(?)

  110. pep.

    Anybody ever used ESessions?

  111. Zash

    There's https://xmpp.org/extensions/xep-0396.html but it's pretty new and I haven't heard about anything using it

  112. pep.

    https://xmpp.org/extensions/xep-0218.html

  113. Zash

    Maybe one time in 2008

  114. Zash

    Back when we had working Jingle VoIP and video chat

  115. Zash

    On phones!!!!1

  116. Zash shakes his N900

  117. pep.

    :D

  118. pep.

    So yeah reading about XTLS and the first condition being to have an x509 cert, that's going to be meh

  119. pep.

    "typically self-signed and automatically generated by an XMPP client", and we come back to the same issues we have with verifying fingerprints

  120. Zash

    Yeah, that's kinda meh

  121. Zash

    You can do TLS without certs

  122. pep.

    But then what do you trust

  123. Zash

    You trust that the NSA is too lazy to MITM your cat pictures

  124. Zash

    Send some hash through the XMPP channel to the other party and verify it that way

  125. Zash

    Eg like the channel binding hash used in SCRAM-PLUS

  126. pep.

    https://www.youtube.com/watch?v=AsXKS8Nyu8Q

  127. Zash

    Then you get a channel should be about as secure as the XMPP path

  128. pep.

    Zash, thanks for volonteering! ✎

  129. pep.

    Zash, thanks for volunteering! ✏

  130. Zash

    pep.: done. prosody already supports this ;)

  131. pep.

    You mean 247 + encrypted session?

  132. Zash

    since jingle is purely a client thing and all the server needs is to route iq stanzas :)

  133. pep.

    That's all client stuff right

  134. pep.

    pff

  135. pep.

    I knew there was a trick

  136. jonas’

    :D

  137. Zash

    One does not simply solve the key problem

  138. Zash

    If OMEMO or some other E2EE had full stanza encryption you could have bootstrapped secure XTLS over that

  139. pep.

    The thing here with clients negociating encrypted sessions is that we can't even use DANE-like things right?

  140. jonas’

    yes

  141. pep.

    Zash, then you trust that you OMEMO sessions is "Secure"

  142. jonas’

    you have to trust something

  143. pep.

    yes

  144. pep.

    Trust, a complicated story.

  145. pep.

    session*

  146. Zash

    There's DANE for S/MIME so it's not entirely irrelevant

  147. pep.

    I hear you should not use S/MIME anymore for emails at least, (following the efail things. https://media.ccc.de/v/35c3-9463-attacking_end-to-end_email_encryption)

  148. jonas’

    aren’t all the efail things broken cilents which will be fixed eventually?

  149. Zash

    Even if you manage to convince E2EE enthusiasts to trust DNSSEC...

  150. jonas’

    or is there something conceptually kaputt with S/MIME?

  151. pep.

    jonas’, I think there's a bit more to it, as in it doesn't include checksum or sth? Don't quote me on this, watch the talk if you have time

  152. Zash

    Everything is broken

  153. jonas’

    I don’t like "{watch,read,…} $thing" replies

  154. pep.

    Either that or I watch it again and quote it for you :/

  155. jonas’

    hm

  156. pep.

    let me find the specific parts

  157. Zash

    jonas’: I looked at your message but I did not understand it

  158. jonas’

    pep., I’m going to be busy for the remainder of the day anyways

  159. pep.

    > S/MIME doesn't have a MAC (Message Authentication Code), which means it cannot detect by standards wether a message was changed or not And apparently the Efail-related changes to S/MIME are: > It is therefore recommended that mail systems migrate to using AES-GCM as quickly as possible ^ Efail CBC Gadget attack, and for direct exfiltration attack: > Clients SHOULD treat each of the different pieces of the multipart/mixed construct as being of different origins. So yes that's a client issue, but the guy says "You can just try to convince your email client not to do any external connection. [..] for a cryptographer, this means _broken_"

  160. pep.

    Apparently OpenPGP is a bit better in a way that it has MDC, Modification Detection Code, but not all keys do this. It was added as info on the key directly for backwards compatibility. And lots of keys don't. Also the standard was not entirely clear what to do with MDC errors, and would still pass the payload to clients