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