XMPP Council - 2013-09-12


  1. Zash

    Why, Dave Cridland, why?

  2. ralphm

    Zash: disappointed he joined Twitter?

  3. Zash

    Who what why where how?

  4. Zash

    re http://logs.xmpp.org/council/130911/#19:47:26

  5. Kanchil

    Zash: http://logs.xmpp.org/council/130911/#19:47:26: Chatroom logs for council@muc.xmpp.org (Wednesday, September 11, 2013)

  6. Dave Cridland

    Zash, Certificate pinning via TACK?

  7. Dave Cridland

    Zash, Seems like a substantial amount of work for little gain. You can get the same general protection from DANE - that is, protection from third-party CAs issuing bad certs - with a lot more, for less effort.

  8. Zash

    Dave Cridland: But TACK seems to have a bigger marketing budget!

  9. Zash

    So it'll win!

  10. Zash

    :(

  11. Dave Cridland

    The advantage of TACK is that is handles this particular pinning case without infrastructure support. That's certainly useful, of course.

  12. Zash

    ralphm: Why is Thijs "xnyhps" not on planet jabber yet? :)

  13. Tobias

    but TACK doesn't seem to be implemented in the foreseeable future, or is it?

  14. Zash

    DNSSEC deployment isn't that fast either

  15. Dave Cridland

    Tobias, TLSlite implements it I think. I assume so anyway.

  16. Dave Cridland

    Zash, That *seems* faster to me.

  17. Tobias

    TLSlite, what's that? the python tls implementation

  18. Zash

    Something like HSTS for XMPP should be fairly simple ...

  19. Tobias

    is HSTS really needed? TLS is the default in the XMPP world, unlike the HTTP world

  20. Dave Cridland

    The intent is to protect against future downgrade attacks.

  21. Zash

    Right.

  22. ralphm

    Zash: because I'm slow

  23. Tobias

    Dave Cridland, downgrade from TLS to non-TLS?

  24. ralphm

    Zash: and had a funeral yesterday

  25. Zash

    Tobias: Strip the starttls advertisment.

  26. Zash

    ralphm: Oh, sorry. No hurry.

  27. Dave Cridland

    ie, I connect to my server, and get my connection policy blob. Next day, I connect to my server, and it has no TLS, but my connection policy blob says my server always offers TLS, so I ditch the connection.

  28. Tobias

    right

  29. Tobias

    but shouldn't clients complain anyway if TLS is not available?

  30. Zash

    We could just never allow non-TLS if TLS succeeded once.

  31. Tobias

    Zash, right..or that

  32. Zash

    And never allow invalid certs if the cert was valid once

  33. Zash

    etc

  34. Dave Cridland

    Zash, There are operational issues there, I suspect.

  35. Tobias

    could completely life in the implementations

  36. Tobias

    without need of standard

  37. Zash

    Yeah

  38. Zash

    Something like HSTS would be an explicit approval of doing that.

  39. Zash

    I'm not sure we really need it

  40. Dave Cridland

    Zash, More importantly, that's a hand-waving exercise - there's no way to know if your clients support that, and there's enough kinks and choices that a pathway through to some kind of downgrade might be important.

  41. Dave Cridland

    For real entertainment, we could have a XMLSec signed document with the connection security policy in it, and then be able to access that via a number of methods. But hey.

  42. Kev

    iq:get after authentication.

  43. Kev

    I win.

  44. Tobias

    aren't you supposed to be holidaying? ;)

  45. Zash

    Having DANE records published also implies that tls should be supported.

  46. Dave Cridland

    I was thinking in terms of iq:get from other servers and such.

  47. Dave Cridland

    Zash, Yes, this is certainly true.

  48. Kev

    Tobias: Never reveal in public when someone's not at home.

  49. Kev

    Tobias: And yes, although I'm back home now.

  50. Tobias

    Kev, ah.oops.right..sry

  51. Dave Cridland

    Tobias, It's OK, I'm sure Kanchil keeps an eye on the place.

  52. Tobias

    Dave Cridland, sure

  53. Tobias

    cool...drag and drop invite worked for waqas :)

  54. waqas

    Hello

  55. Tobias

    waqas, we're just discussing security improvements to XMPP

  56. waqas has strong opinions on that...

  57. Tobias

    waqas, which are?

  58. waqas

    Well, there are multiple separate aspects of the XMPP network that are weak. Bad clients (cert verification issues, cipher suites, etc), bad server deployments (SSLv2, bad cipher suites, PLAIN over unencrypted), server software defaults, etc

  59. waqas

    Then we have the separate class of security missing entirely from XMPP: encrypted jingle, e2e encryption, etc

  60. waqas

    Some of this requires activism, while some requires standards work

  61. Tobias

    bad ciphers and so probably falls into the activism area

  62. waqas

    Something like a validation service might help the server deployment side of things a lot

  63. Kev

    I think an Informational XEP here might be in order.

  64. waqas

    I'm +1 to that

  65. Tobias

    also i'd interesting to have some kind of MITM protection, i.e. if your usual cert is suddenly replaced by some other strange cert (i know it sounds vague)

  66. waqas

    It would also be nice if support for that XEP was required to get on the xmpp.net server list :)

  67. Tobias

    waqas, the xmpp.net list is a whole other topic...it doesn't seem to really scale

  68. Kev

    Tobias: I think an Informational for that is interesting too.

  69. waqas

    A validation service would help it scale to some degree. For better or worse, a lot of public XMPP deployments want to be on that. If the XSF can use that to upgrade the security of the XMPP network, that's a good thing IMO.

  70. ralphm

    another thing is that server implementations generally don't alert admins about bad certs

  71. Tobias

    Kev, what would be the rough gist of it?

  72. Kev

    Tobias: Sounds too much like work for a holiday :p

  73. Dave Cridland

    You've seen PSA's new I-D on XMPP and TLS?

  74. Kev

    Only that it exists.

  75. Tobias

    Kev :P

  76. Kev

    That covers cyphers, but not pinning stuffs, I think?

  77. Dave Cridland

    Right, it addresses much of waqas's easily addressable concerns.

  78. Kev

    I'll read it at some point :)

  79. waqas

    It seems like a good start

  80. Dave Cridland

    waqas, But yes, we should require claims of conformance to various specifications to be listed, I think.

  81. waqas

    Does anyone know how bad compatibility issues are with dropping SSLv3? Is most everything supporting TLS1.0 these days?

  82. Dave Cridland

    waqas, Most of the figures I've seen relate to browsers. I don't know about XMPP, I suspect we're generally TLSv1.0 and up.

  83. ralphm

    I also want to note that SSLv3 is entirely not supported, spec-wise.

  84. ralphm

    and never has been for XMPP 1.0

  85. waqas

    I assume most of you have read xnyhps's (Adium dev) recent posts regarding client cipher suites?

  86. Dave Cridland

    I've not. Link?

  87. Zash

    https://blog.thijsalkema.de/blog/2013/08/26/the-state-of-tls-on-xmpp-1/

  88. waqas

    The three "State of XMPP TLS" posts: https://blog.thijsalkema.de/

  89. waqas

    He has been gathering data on what cipher suites, etc different actual clients support

  90. waqas

    This sort of information can feed directly into client+server software configuration defaults, and given most deployments don't bother changing defaults, would help improve security

  91. waqas

    It also gives data required for pestering software vendors to fix their stuff

  92. waqas

    Also, jabber.org might be able to do a whole lot in getting deployments updated. If jabber.org disabled certain bad things, e.g., SSLv3 or export ciphers or required TLS crypto for everyone except Google (can the software pull that off?) or Google went away, etc, other deployments of both servers and clients would simply be forced to follow.

  93. waqas

    Few compatibility concerns in XMPP land has been as strong as the desire to stay compatible with jabber.org, and this is a fact which can be used to force change

  94. waqas

    *have

  95. Dave Cridland

    waqas, I think M-Link's manuals are publi, and as such, I think I can safely say that TLS options in M-Link are global, and not tied to peer controls - TLS requirement and certificate pinning are at the peer level, though.

  96. ralphm

    waqas: the problem with whitelisting GTalk is that you have to do it based on the resolved host, because there are so many domains there.

  97. Tobias

    right...or delegating new user registrations to servers which have decent security

  98. ralphm

    I think even Prosody doesn't support it in that way.

  99. waqas

    Yep, which is bad, but such a thing would be strictly better than what we currently have

  100. Dave Cridland

    ralphm, Ah, good point. So jabber.org couldn't simply whitelist Google; it does these things by name.

  101. waqas

    And I freely admit it's a bit of wishful thinking, which while possible, isn't implemented anywhere

  102. Zash

    ralphm: Plugin could do that ;)

  103. Dave Cridland

    Of course, this is one thing we all thought we could do with Google dropping S2S, except they kind of haven't.

  104. waqas

    And I suspect they might not for a long time

  105. waqas

    Heck they might decide to never drop it, and we'll have this insecure s2s situation forever

  106. ralphm

    Zash: of course, but the existing config support for that only works on domains

  107. waqas

    I notice mention of HSTS in the room history. That's a nice-to-have thing. We don't have a spec like that, but a client notifying me when it connects to a server and has stuff changed (different cert, but more importantly: weaker security), would be useful to me at least

  108. waqas

    I'm not entirely clear on what this discussion is. Part of the council meeting? Just random discussion after it? :)

  109. Zash

    waqas: Do you think we need a HSTS-ish spec?

  110. Zash

    spec/protocol

  111. Dave Cridland

    waqas, Random discussion because we'd not left since yesterday.

  112. waqas

    Could the current HTTP-ish HSTS spec be used in some way? I don't recall what it looked like. Was it just an HTTP header? If so, a stream feature would be all the spec work required?

  113. Zash

    waqas: Header saying don't accept plain connections for N time

  114. ralphm

    so, everyone here, if you are planning on going to the XMPP Summit in Portland, and haven't signed up in the wiki yet: WHY NOT!

  115. Zash

    ralphm: Expensive and far away.

  116. Dave Cridland

    And if you're not coming, I think the six of us who are will find a really good bar and whole up for the evening.

  117. Dave Cridland

    Hole up, even.

  118. waqas

    Dave Cridland: MattJ and I don't drinkā€¦ we'll just be staring at you the whole time

  119. Tobias

    waqas, +1 on that

  120. ralphm

    Zash: to be sure, I wasn't asking why people were not planning to come.

  121. ralphm

    Zash: it appears that we have a bunch of people that are going to, but we don't know about them

  122. Tobias

    Zash, was fosdem acceptable regarding the costs?

  123. Dave Cridland

    waqas, You're coming?

  124. waqas

    Dave Cridland: Well, I'm in the US, and have a realtimeconf ticket, so: probably

  125. Zash

    Tobias: I think so. But I skimped on accomodation costs by staying with friends.

  126. Tobias

    waqas, US must have a nice visa process ^^

  127. Dave Cridland

    Tobias, Yeah, but he has to get through TSA with that name...

  128. waqas

    Tobias: Surprisingly easier than Belgium. It was a lot more well-defined.

  129. Tobias

    Dave Cridland, he could just put a turban on and would be fine

  130. waqas

    And the TSA was being weird both times I arrived. The security seemed to be missing entirely at JFK.

  131. Dave Cridland

    JFK can be hit and miss. It's usually horribly crowded for me, though hey seem to be rebuilding it.

  132. ralphm

    I never went there

  133. waqas

    No scanners, no questioning, no baggage checks (I literally could have walked out with anyone's luggage both times), I saw no real evidence of the TSA

  134. ralphm

    AMS->PDX FTW

  135. Tobias

    PDX?

  136. ralphm

    Tobias: Portland, OR

  137. Tobias

    ahh

  138. Dave Cridland

    ralphm, I'll be CWL->AMS->???->DCA, and DCA->PDX, then PDX->AMS->CWL.

  139. m&m

    oy

  140. ralphm

    Dave Cridland: AMS->PDX->SFO->AMS for me

  141. ralphm

    m&m: hi

  142. m&m waves

  143. ralphm

    waqas: go sign up at http://wiki.xmpp.org/web/Summit_14

  144. Dave Cridland

    ralphm, Right; I can't fly into DCA from outside the US, and refuse to fly into Dulles, so...

  145. Kanchil

    ralphm: http://wiki.xmpp.org/web/Summit_14: Summit 14 - XMPP Wiki

  146. waqas

    Well, I need to check out of this hotel, was just about to leave when Tobias invited me here, so I'll be on a train for an hour. Hopefully my input was useful in some way :)

  147. Dave Cridland

    waqas, Sign up first.

  148. waqas

    Done

  149. ralphm

    waqas: what Dave Cridland said, because we can then maybe still do a hotel package deal

  150. waqas

    Ah good, I was wondering about what to do about a hotel

  151. Dave Cridland

    That's now 6 awesome people. And me.

  152. Dave Cridland waits for someone else to tell him he's awesome too.

  153. Kev

    I won't be able to make it.

  154. waqas

    I'm running off now folks

  155. waqas waves

  156. Kev

    Bibi.

  157. ralphm

    Kev: good save regarding Dave's ponderance

  158. Dave Cridland

    Yeah, thanks guys.

  159. Zash

    Dave Cridland: You're awesome.

  160. ralphm

    For what it is worth, I did include you in my oob assertion.

  161. m&m

    I'm going to be missing out myself

  162. m&m

    would have been good to hang out with such awesome people

  163. m&m

    and Dave

  164. ralphm

    hibyehi stpeter