XSF Discussion - 2014-03-01


  1. Lance has left

  2. emcho has joined

  3. emcho has left

  4. Tobias has left

  5. emcho has joined

  6. emcho has left

  7. emcho has joined

  8. Santiago26 has joined

  9. emcho has left

  10. emcho has joined

  11. Santiago26 has left

  12. emcho has left

  13. emcho has joined

  14. Santiago26 has joined

  15. xnyhps has left

  16. emcho has left

  17. Santiago26 has left

  18. fsteinel has joined

  19. emcho has joined

  20. dwd

    Kev, WHile I remember, you had objections to my XEP-0001 pass; could you post them to the list so others can agree/disagree?

  21. Kev

    Yes. It's in my todo system. This isn't particularly time-critical though, is it?

  22. dwd

    Kev, I think that the correct thing is that Editor approves Humour, but will run things past COuncil members and other advisors individually to ensure sanity. Possibly mandate that it's never me, since it hasn't ever been as far as I know. :-)

  23. dwd

    I'd like to keep momentum up on the discussion, if possible, then we can get it all over with.

  24. Kev

    OK. I'll try to get to it sooner than later, then.

  25. dwd

    Ta.

  26. Kev

    I'm not really sure I like the thought of there being any XEPs for which the approving body isn't either Council or Board.

  27. dwd

    These *are* Humorous ones. Maybe it needs "in consultaion with the XMPP Council Chair" specifically?

  28. Kev

    It seems somewhat self serving, but I'd be happy with direct approval by council chair, yes.

  29. Kev

    Although TBH I'm not sure what the problem with just using Council is.

  30. Kev

    What usually happens is just someone says to Council, quietly, "I'll be writing along these lines" and Council says "Fine, go ahead".

  31. fsteinel has left

  32. Kev

    The counter to "These *are* Humorous ones." being "These *are* XEPs".

  33. Kev

    If we went with XEP Editors, we'd need to put in place some sort of rules for meetings and approval process, I think, which we don't currently have.

  34. Kev

    And being able to take a XEP through every step of the process autonomously dramatically changes the scope of the Editor team.

  35. emcho has left

  36. xnyhps has left

  37. Zash has joined

  38. Zash has left

  39. Tobias

    anyone happen to know if XEP-0027 also works for MUCs? and wether that's implemented?

  40. Kev

    27 doesn't even work for presence :)

  41. xnyhps

    27 doesn't work.

  42. Kev

    And no, it wouldn't work for MUC.

  43. Kev

    Basically, don't go near 27.

  44. Tobias

    ok

  45. Tobias

    with doesn't work for presence you mean you can't encrypt presence messages?

  46. Tobias

    with doesn't work for presence you mean you can't encrypt presence stanzas?

  47. xnyhps

    You can sign presence or encrypt (but not sign) messages. That's all.

  48. Kev

    No, I mean that there's no protection against replay attacks.

  49. Kev

    It's full enough of holes that we should just stay well away.

  50. Kev

    Thus the mail I just sent to council@ about getting rid of it.

  51. Tobias

    PGP for email doesn't have that either, not?

  52. xnyhps

    Tobias: PGP signatures contain a datestamp.

  53. xnyhps

    in email.

  54. Tobias

    Kev, http://wiki.xmpp.org/web/XMPP_E2E_Security i've started to collect an overview about all proposals out there

  55. Tobias

    xnyhps, ahh..ok

  56. Kev

    You should probably mention that OTR doesn't have clean discovery.

  57. Kev

    Unless you know the person you're talking to has OTR from out-of-band discovery (e.g. talking to them), the experience is quite horrid.

  58. xnyhps

    I disagree with the "Yes"es for Authenticity and Integrity with PGP.

  59. Kev

    Right.

  60. Tobias

    xnyhps, it doesn't provide those?

  61. xnyhps

    Nope.

  62. Kev

    We should really forget 27 exists, and get rid of it.

  63. xnyhps

    Your messages aren't signed, any attacker can replace them with any other encrypted message.

  64. Kev

    Presumably in the other order, or we wouldn't remember what we were getting rid of.

  65. Tobias

    xnyhps, that's for XEP-0027, not for email usage of PGP right?

  66. xnyhps

    Yes.

  67. Kev

    Tobias: It provides complete protection as long as you have absolute faith in your server, their server, and all the networking in between.

  68. Tobias

    maybe i just expected XEP-0027 to be too much like email PGP

  69. Tobias

    Kev, right...why do i need e2e then

  70. Tobias

    :)

  71. Kev

    Yes.

  72. Kev

    See earlier question about burning 27 with fire.

  73. xnyhps

    +1 for fire.

  74. Kev

    s/question/comment/

  75. Tobias

    !xep 27 doesn't have discovery support either it seems

  76. Tobias

    at least i see nothing about disco in the XEp

  77. Kev

    Fire

  78. Kev

    It

  79. Kev

    Burn

  80. Kev

    With.

  81. Tobias

    updated the table...will add a couple sentences in the section above

  82. xnyhps

    I also disagree with the "No" for multiple resources for OTR.

  83. xnyhps

    But maybe it's also not "Yes". :P

  84. Tobias

    right..the detailed answer probably doesn't fit in a table cell

  85. Tobias

    but i could add a paragraph above in the section of OTR to it

  86. Tobias

    also wondering what version we should describe there? OTRv2 or OTRv3?

  87. Tobias

    what's used out there?

  88. xnyhps

    I don't actually know, beyond Pidgin and Adium.

  89. xnyhps

    (I'd also say "Malleable encryption" should be "n/a" for PGP, as it doesn't even have authenticity. Sorry for pestering you, I can't find my xmpp.org login.)

  90. Kev

    I wonder if it'd be interesting to do a 'real' gpg spec.

  91. Tobias

    it'd at least have great support for offline messages :)

  92. Kev

    It would.

  93. Kev

    And at least the methods for trust are established.

  94. dwd

    In fairness, XEP-0027 is better protection than many of the recent commercial "secure IM" services that seem to have sprung up.

  95. Tobias

    dwd, to what are you referring exactly?

  96. dwd

    Tobias, Most of the new security bandwagon services seem based around similarly, or worse, flawed models.

  97. Tobias

    *most* probably qualifies here, considering the ton on new services

  98. Tobias

    you guys know of any implementation of RFC 3923?

  99. dwd

    I don't. I have heard people say there hasn't ever been one.

  100. dwd

    In fairness, 3923 isn't even a bad design, as far as I can tell, it's just ugly.

  101. Tobias

    don't RFCs require implementation at some level?

  102. dwd

    Only to move to Draft, IIRC.

  103. Tobias

    ah..ok

  104. dwd

    Which is vaguely silly - they shifted the meaning of each level while keeping the requirements largely the same.

  105. Alex has joined

  106. Zash has joined

  107. Ash has joined

  108. Ge0rG

    isn't it finally time to consider one-to-one chats as a subclass of multi-user chats, security-wise? After all, you have your smartphone and your desktop connected (or connecting later) and want all your IM backlog there

  109. Ge0rG

    btw, how did WebRTC solbe the certificate/identity management problem for DTLS?

  110. Ge0rG

    *solve

  111. Zash

    There's a fingerprint in the SDP blob.

  112. Ge0rG

    Zash: how is that supposed to solve anything?

  113. Tobias

    users obviously will meet in person to validate those

  114. Zash

    And I don't know if there are actual certificates.

  115. Ge0rG

    if I meet my users in person, what do I need WebRTC for?

  116. Zash

    Ge0rG: Define "anything".

  117. Ge0rG

    Zash: anything is the set of IT security properties that a cryptographic protocol should be able to solve: integrity, authenticity, privacy, nonrepudiation|deniability, and one or more unimportant ones

  118. Zash

    Ge0rG: And a DTLS fingerprint does not?

  119. Zash

    Assuming you shuffle that securely to the other party, along with the rest of the SDP stuff

  120. Ge0rG

    Zash: so you are assuming a secure channel between two parties, which you use to construct a secure channel between these two parties?

  121. Zash

    The connection to a common server, yes. :)

  122. Ge0rG

    Zash: a trusted common server that does not manipulate your packets

  123. Zash

    Yes.

  124. Kev

    If you don't trust the server, when it's the server providing the application, you're in some amount of trouble.

  125. Zash

    That.

  126. Ge0rG

    ok, now that's where XMPP is different from WebRTC

  127. Kev

    Yes.

  128. Ge0rG

    does WebRTC support federation?

  129. Kev

    Different layer.

  130. Kev

    Or, kinda.

  131. Ge0rG

    (actually, that question does not matter.)

  132. Ge0rG

    I just realized that me trusting my own server does not help at all in establishing a federated session through a different, untrusted, server

  133. emcho has joined

  134. emcho has left

  135. emcho has joined

  136. emcho has left

  137. emcho has joined

  138. Maranda has joined

  139. Ge0rG

    who can contribute to the xmpp.org wiki?

  140. Zash

    A bunch

  141. Zash

    You, if someone gets you an account :)

  142. Ge0rG

    ah, so the formal requirement is "get yourself added"

  143. Tobias

    right

  144. emcho has left

  145. Alex has left

  146. Maranda has left

  147. Tobias

    basically you just ask for an account in the jdev chatroom and some admin will likely create an account for you

  148. Jef has joined

  149. emcho has joined

  150. emcho has left

  151. emcho has joined

  152. emcho has left

  153. intosi has left

  154. Zash has left

  155. Tobias has joined

  156. dezant has left

  157. dezant has joined

  158. Jef has left

  159. dwd has left

  160. intosi has joined

  161. emcho has joined

  162. emcho has left

  163. emcho has joined

  164. emcho has left

  165. emcho has joined

  166. emcho has left

  167. emcho has joined

  168. emcho has left

  169. emcho has joined

  170. emcho has left

  171. emcho has joined

  172. emcho has left

  173. emcho has joined

  174. emcho has left

  175. emcho has joined

  176. emcho has left

  177. Emil Ivov has joined

  178. Emil Ivov has left

  179. emcho has joined

  180. emcho has left

  181. emcho has joined

  182. emcho has left

  183. emcho has joined

  184. emcho has left

  185. emcho has joined

  186. emcho has left

  187. emcho has joined

  188. emcho has left

  189. emcho has joined

  190. emcho has left

  191. emcho has joined

  192. xnyhps has left

  193. Ash has left

  194. Tobias has joined

  195. xnyhps has left