XMPP Council - 2017-10-11

  1. Link Mauve

    Hi, I’m ill today so I won’t be here, good night. \o_

  2. Tobias

    get well

  3. Tobias


  4. Tobias

    1) Roll call

  5. SamWhited


  6. daniel


  7. Tobias

    Link Mauve is excused as he's ill

  8. Tobias

    have pinged dave in another channel

  9. Tobias

    2) Minute taker

  10. Tobias

    I can take minutes if there's no other volunteer

  11. daniel

    Please do. I'm traveling. Will do the minutes when I get back

  12. Tobias


  13. Tobias

    3) General reminder to vote on things, see pending votes column in trello https://trello.com/b/ww7zWMlI/xmpp-council-agenda

  14. SamWhited

    Jingle Encrypted Transports was apparently already published, but it's in that column

  15. SamWhited

    as was the color one.

  16. daniel

    Maybe Because the two weeks ran out?

  17. SamWhited

    Could be, I'm not actually sure which is wrong.

  18. daniel

    I don't think I voted on either. But I'm fine with it

  19. Tobias


  20. Tobias

    4) Vote on advancing XEP-0387: XMPP Compliance Suites 2017

  21. Tobias

    to Draft that is

  22. Tobias

    I'm +1

  23. daniel


  24. SamWhited

    As the author I'm +0

  25. Tobias

    alright. I suppose the rest will vote on list

  26. Tobias

    5) Consider deprecation of Message Archiving ( https://xmpp.org/extensions/xep-0136.html )

  27. Kev

    I don't think that's in LC, is it? I don't remember seeing an LC recently, at least.

  28. Kev


  29. dwd

    Mea culpa, meeting was overrunning and I didn't notice the time.

  30. SamWhited

    oops, yes, that was supposed to be for issuing a LC, not for advancing to draft

  31. daniel

    I figured as much

  32. Tobias


  33. dwd

    I was just coming to that conclusion. I'm fine for a last call.

  34. Tobias

    LC for advancing it to Draft

  35. Tobias

    SamWhited, why do you want to deprecate XEP-136?

  36. SamWhited

    RE Message Archiving: we've discussed this before, but I'd like to complain about it again. I was having a conversation with someone the other day that was implementing a server and they said something about having trouble with message archiving. I mentioned that most people seem to use MAM now and that they should probably do that instead and got the usual "but archiving is the recommended one, why would I do MAM?"

  37. daniel

    I think we should advance mam

  38. daniel

    Before we deprecate something else

  39. dwd

    SamWhited, I agree with the sentiment, but let's LC MAM first.

  40. daniel

    I'm entirely with you on the confusion problem

  41. SamWhited

    I think we either need to advance MAM and deprecate archiving, or if that's not ready we need to go ahead and deprecate archiving to prevent confusion and just only have an experimental history XEP.

  42. Tobias

    yeah...I'd prefer advancing MAM first too

  43. SamWhited

    Since I've heard that "more work on MAM is coming soon" for at least a year, I'm not sure that it's ready to advance, but I would be all for issuing a LC and finding out.

  44. daniel

    I don't think we should deprecate before there is something else

  45. Kev

    I don't like deprecating in favour of something with lower advancement, but in this case I think the case is fairly compelling.

  46. SamWhited

    I disagree, I think we should absolutely deprecate if the community has standardized on something else. Even if that thing is experimental, it can still be the recommendation of this council.

  47. dwd

    SamWhited, Again, I agree with the sentiment, but I'd want to try pretty hard to nail '313 before deprecating without a replacement.

  48. Kev

    It's not like there's nothing else, just that the something else isn't Draft.

  49. Kev

    Whether we continue tweaking MAM or not, we know it's already vastly better than 136.

  50. SamWhited

    But I do agree that issuign a LC for MAM seems like a reasonable step, maybe I'm wrong about it needing more work.

  51. Ge0rG

    does the Council want to encourage 136 implementations until MAM is finished?

  52. Kev

    Ge0rG: Hopefully not :)

  53. daniel

    Though I admit that the mam situation is a bit problematic. (lots of people use it but it's not really being worked on)

  54. SamWhited

    I hope not too

  55. daniel

    But we should fix that situation

  56. Tobias


  57. Ge0rG

    Kev: in that case deprecating it now might be good?

  58. dwd

    Ge0rG, I take your point, but I would prefer a push on MAM *first*. If that doesn't work, let's revisit.

  59. SamWhited

    That is a compromise I can live with. In that case, I would like us to vote on a LC for MAM if possible.

  60. Kev

    I can probably arrange for a 313 author to request an LC if you want ...

  61. SamWhited

    This is the second or third time I've run into this specific XEP as a source of confusion, so I'm rather eager to find a solution

  62. SamWhited

    Or we can just issue one, no?

  63. Kev

    SamWhited: It was a flippancy, Matt and I are the authors.

  64. dwd

    Kev, Are you so doing? I think you need to ask an Editor, if you can find one...

  65. daniel

    SamWhited: does that work without the author requesting it?

  66. daniel

    Or is that a good idea without the author requesting it

  67. SamWhited

    daniel: It seems like a good way to encourage authors to submit the changes they've said they have almost ready for a year or more :)

  68. Kev

    I don't think Council needs the author to request it, although doing so when the author thinks it isn't ready might be a poor idea.

  69. Kev

    Anyway, issue the LC. No harm will come, as long as you don't then advance it prematurely :)

  70. daniel

    Let issue a LC. Maybe that encourages some discussion. Or the author to submit more changes and thus cancel lc

  71. Kev

    (Or issue the vote for an LC, as clearly I wouldn't tell Council how to vote)

  72. Ge0rG

    Kev: if 136 is not an alternative to 313, deprecating 136 is independent of pushing forward 313, right?

  73. Tobias

    sure...fine with issuing a LC

  74. SamWhited

    Thanks all. +1 to LC from me (obviously)

  75. Kev

    Ge0rG: I'm not Council, and Council don't want to deprecate 136 until 313 is LCd, so ... path of least resistance.

  76. daniel

    +1 for the LC

  77. dwd

    I would be happy to vote on an LC for 313 now. (And will vote for, FWIW).

  78. dwd

    Oh. So yeah, -1.

  79. dwd


  80. dwd

    +1. I meant +1.

  81. Tobias

    ok..to make it clear in the history let's start fresh

  82. Tobias

    6) Vote on issuing a LC on MAM

  83. Tobias


  84. dwd


  85. SamWhited


  86. daniel


  87. Tobias


  88. SamWhited

    I'll add a card; thanks all.

  89. Tobias

    7) Deprecate XHTML-IM

  90. daniel


  91. daniel

    Link Mauve loves that xep

  92. dwd

    Where did that one spring from?

  93. Tobias


  94. Tobias

    he wants us to discuss this yearly

  95. Tobias


  96. dwd

    Oh. Has it been discussed on the list yearly, too?

  97. daniel

    I think that needs list discussion

  98. Tobias


  99. daniel

    Even though I personally hate that xep and would like to deprecate it I think it does have a lot of fans

  100. dwd

    Yeah. Last time it was discussed on the list was back in December.

  101. SamWhited

    Okay, back to this

  102. Ge0rG

    I love XHTML-IM.

  103. daniel

    Or we should maybe do some 'markup in im' xep

  104. SamWhited

    Similar to the MAM thing, I was playing around with another web client a few days ago and found, yet again, an implementation of XHTML-IM that simply dumped HTML into the DOM and made it trivial to implement XSS's

  105. dwd

    daniel, Down. Mark*down*.

  106. daniel

    Since markup seems to be what cool IMs do theses days

  107. SamWhited

    I have never found an XHTML-IM implementation that didn't have this issue (or rather, some didn't, but they did have it originally and it had been fixed)

  108. daniel

    *that *

  109. SamWhited

    Literally "never", that is not me making a grand statement for the purpose of making a point.

  110. Zash

    Big warning in <blink> and red letters at the top of the document?

  111. SamWhited

    I'm sure *someone* has done this right the first time, but it seems that the default is that the spec encourages people to do it wrong. By leaving it as a recommendation I think we are encouraging security issues.

  112. daniel

    SamWhited: yes I'm personally all in favor for the same arguments. I think we should even do the 'what ever is worse than deprecated'

  113. Ge0rG

    SamWhited: all modern applications are full of security issues.

  114. daniel

    But it does need list discussion

  115. SamWhited

    Even if we're not comfortable deprecating Message Archiving until there is a replacement, I think this is a security problem and therefore should absolutely be obsoleted (not just deprecated) as soon as possible.

  116. daniel

    Especially if you want to get Link Mauve on board

  117. Tobias

    yeah, SamWhited, do you mind writing a mail to standard about the plan of deprecating it and we'll see what comes out of that?

  118. daniel

    He *loves* xhtml

  119. SamWhited

    Sounds good, I'll write something up for the list.

  120. Tobias


  121. SamWhited

    Thanks for humoring me.

  122. Tobias

    7) Date of next

  123. Tobias

    same time next week

  124. daniel


  125. Tobias


  126. SamWhited


  127. Tobias

    8) AOB

  128. daniel

    None from me

  129. dwd

    Just a heads-up that I'll be writing up Surevine's TOTP approach into a XEP or two shortly.

  130. Tobias


  131. SamWhited


  132. SamWhited

    Tobias: time based multi-factor auth (Google Authenticator, Yubico Auth, etc.)

  133. Tobias


  134. Tobias


  135. Tobias

    no other AOB

  136. Tobias bangs the gavel

  137. Tobias

    thanks everybody

  138. SamWhited

    I can't wait to see that; I'd love to be able to use my yubikey as a second factor in Conversations one of these days

  139. Ge0rG

    I'd be happy with per-device passwords already.

  140. jonasw

    I can’t believe people would simply dump an XHTML-IM tree in anything capable of doing something bad with that.

  141. dwd

    Ge0rG, That has to be included.

  142. jonasw

    that makes me sad.

  143. dwd

    Ge0rG, Otherwise you end up having to hit the TOTP device every time you switch networks.

  144. Ge0rG

    jonasw: people go for convenience first.

  145. jonasw

    Ge0rG, insert rage here

  146. Ge0rG

    dwd: right. There needs to be some sensible trade-off here.

  147. moparisthebest

    yubikey might have some value there

  148. moparisthebest

    but otherwise, all apps are on the phone

  149. moparisthebest

    so to login to conversations you need your phone anyway, and you are back to 1 factor no?

  150. Ge0rG

    moparisthebest: the trick is to have a _second_ phone for 2FA!

  151. moparisthebest

    ah so user friendly Ge0rG :P

  152. dwd

    moparisthebest, You're right, but the 2FA control is on the account, so this is a generally recurring problem.

  153. Ge0rG

    we really need some notion of device identity.

  154. dwd

    moparisthebest, I can recommend a watch for this, BTW. :-)

  155. moparisthebest

    Ge0rG, you can already see your other online devices right?

  156. Ge0rG

    moparisthebest: yes and no. Let me write a short mail to standards@.

  157. moparisthebest

    I'm still undecided on the whole thing, I think it's fine for people that want it, I don't think I'd want it

  158. moparisthebest

    I'm not positive it's that much better than just long random passwords for most threats

  159. moparisthebest

    so you've got:

  160. dwd

    moparisthebest, No, it is.

  161. moparisthebest

    1. password leaks, yahoo hacks, etc - long random unique per account password and 2fa protect you the same

  162. moparisthebest

    2. NSA is after you - cracking long random password is harder than hacking your phone and stealing your 2fa stuff

  163. moparisthebest

    3. Kidnapped - same

  164. moparisthebest

    what am I missing? I guess if some random hacks your computer and not your phone? in which case 2fa is an advantage

  165. SamWhited

    The point is that they work together; 1. doesn't actually make sense, it's operating under the assumption that they are two orthogonal things that attempt to solve the same problems. You have to use both together, 2fa is not a replacement for long random unique-per-account passwords.

  166. SamWhited

    Same with two. The point is that they have to crack a long random password *and* steal your 2fa stuff. Doesn't matter which one is harder for any given actor.

  167. moparisthebest

    but for #1 it doesn't make it any harder with 2fa

  168. dwd

    moparisthebest, Yes, it does.

  169. moparisthebest

    #2 the NSA can just do both, *maybe* it makes it a bit harder, fair

  170. moparisthebest

    and I mean who are we kidding, the NSA just hacks your server, it doesn't need your credentials, so that was a dumb example on my part :)

  171. SamWhited

    It does if your bank was storing your password in plain text. Or if it is random, long, and hard to break but your goal is to slow them down even further even if they do break it.

  172. dwd

    SamWhited, Or if you get phished.

  173. moparisthebest

    banks are one of the few places I think 2fa makes sense

  174. SamWhited

    dwd: indeed

  175. moparisthebest

    too bad none of them implement it :'(

  176. SamWhited

    It's also almost not worth using the NSA as an example. Most peoples threat model doesn't include a state level adversary.

  177. moparisthebest

    yep I agree

  178. SamWhited

    ah yah, I missed your last statement on that.

  179. dwd

    moparisthebest, There *is* a problem in that many TOTP implementations store the TOTP secret in the clear, and that's bad. It's difficult (especially in XMPP) to do otherwise, though our implementation at least stores it encrypted in the database.

  180. moparisthebest

    if you do, you should just stay off the internet really :)

  181. moparisthebest

    I guess in my mind TOTP makes more sense for things you log into, do your business, and log out of

  182. moparisthebest

    and less for something you plan on staying logged into forever

  183. moparisthebest

    especially from your phone that doubles as your totp generator

  184. dwd

    moparisthebest, Sure, which is why any time you'd save your password in the client, you need a way to avoid the TOTP.

  185. moparisthebest

    that sounds like a good system then dwd :)

  186. dwd

    moparisthebest, And amazing, we have already implemented most of it. Got to replace the crappy per-client password type thing with a better one I've designed, but it's certainly proved the concept.

  187. dwd

    moparisthebest, The really painful thing isn't merely using TOTP on the phone, BTW. The really painful thing is signing up to TOTP on the phone.

  188. moparisthebest

    yea actually that would be a giant pain

  189. moparisthebest

    back to Ge0rG 's 2 phone thing :)

  190. dwd

    moparisthebest, But yay, because I don't have a solution there at all.

  191. moparisthebest

    what about 2 mirrors?

  192. moparisthebest

    oh, front-facing camera and 1 mirror

  193. moparisthebest

    problem solved!

  194. dwd

    moparisthebest, I suspect that trying to open a totp URI on Android might well actually do the right thing.

  195. moparisthebest

    that's the way, if any totp apps support that

  196. moparisthebest

    I find redhat's the best https://freeotp.github.io/

  197. Tobias

    Minutes are out.

  198. Ge0rG

    moparisthebest: https://mail.jabber.org/pipermail/standards/2017-October/033544.html btw

  199. pep.

    Wow deprecate xhtml-im. Didn't see that coming.

  200. SamWhited

    I try to keep you on your toes :)

  201. pep.

    People are dumb, sure, help them fix their client. Otherwise you can do whatever other markup you want with it. You want markdown, her xhtml-im! You want rST, use xhtml-im

  202. pep.

    use* dumb android