XSF Discussion - 2018-05-02

  1. moparisthebest

    in a xep xml, is there a way to do this:

  2. moparisthebest

    Reference: [&xep0368;]

  3. moparisthebest

    for a protoxep ?

  4. moparisthebest

    like a 'this xep'

  5. jonasw

    moparisthebest, just write "this xep"?

  6. Maranda


  7. jonasw

    moparisthebest, I’ve seen your draft -- are you on a mission to make Zash incredibly sad?

  8. flow

    moar context pls?

  9. jonasw

    flow, https://github.com/moparisthebest/xeps/commit/364a577a30e1d42d6fb169e596921befc2c16873

  10. Maranda stopped at "MUST use HTTPS"

  11. flow

    quite a dance for an xmpp connectiono

  12. lovetox

    So this is like POSH but with added connection infos

  13. lovetox

    though what is the use case

  14. lovetox


  15. lovetox

    is there a use case where we cant put these infos into srv entrys?

  16. jonasw

    lovetox, not sure if one can resolve SRV from within a web client

  17. pep.


  18. Dave Cridland

    moparisthebest, I'm going to need a crapload of reasons why this proposal isn't duplicating DOH etc.

  19. jonasw


  20. daniel

    Because nobody supports DNS over http🙄

  21. daniel

    I see your point though

  22. jonasw

    moparisthebest, have you seen https://xmpp.org/extensions/xep-0156.html#http ?

  23. Wiktor

    jonasw: for discovering domain name and port an extension to XEP 0156 would be IMHO sufficient, but as far as I can see moparisthebest wants something that could contain info about SNI/ALPN to be used as well as public key pins, etc.

  24. jonasw


  25. jonasw

    that doesn’t make sense to me

  26. jonasw

    but I bet there’s a rationale

  27. Wiktor

    especially that public key pinning is being withdrawn from browsers...

  28. ralphm

    Well, yeah. The problem with HPKP *in the browser*, is that if at a point in time, the wrong header was received by the browser, there is no way to undo this, except for waiting until that header's expiry. Besides the actual owner of the website messing up, the other issue is with somebody hijacking your website in some way, if only temporary, and issuing cripling headers.

  29. ralphm

    Of course, for mobile apps, this is different. There, you still have the option to issue a new version of your app.

  30. Ge0rG

    apps should just do cert pinning

  31. Wiktor

    ralphm: yes, but the xeo that moparisthebest is authoring would be more similar to hpkp in the browser (as I guess xmpp clients would not ship with this list and would not update the list as servers change their pins)

  32. ralphm

    Ge0rG: please explain how you handle cert expiry. Unless you meant public key pinning, in which case I will ask: how do you handle revocation in case your secret key is compromised?

  33. Wiktor

    Ge0rG: cert pinning can be more dangerous than key pinning, in case someone revokes your cert you're out of options, see https://scotthelme.co.uk/the-power-to-revoke-lies-with-the-ca/

  34. ralphm

    Wiktor: I think HPKP definitely has merit, so if you can mitigate the above by having some way to recover from faulty headers, yay!

  35. Ge0rG

    ralphm: indeed I'm using "cert pinning" as a loosely defined term for pinning either the SPKI, the certificate or the CA cert.

  36. Ge0rG

    ralphm: which of those should be taken, I'd decide on a case-by-case basis

  37. Wiktor

    ralphm: well, it's just a very sharp blade, if you take extra care then sure, but I wouldn't recommend it lightly

  38. Ge0rG

    ralphm: I think it's not too far-fetched to have a long-living self-signed cert for an app and to roll out a new app version in case of compromise.

  39. Wiktor

    Ge0rG: new app version? that'd tightly couple client to server, for centralized service such as Signal this is OK but for XMPP all clients would need to be upgraded... unless I'm missing something in this design :)

  40. ralphm

    I agree that rolling out a new app is the easier way, but using HPKP in this particular case makes it more seamless to the user. Having to tell your user to upgrade, is a) painful, b) not trivial if you depended on the certificate/key to deliver a notice to the app.

  41. Ge0rG

    Wiktor: I'm only talking of apps that are bound to a given service. For other (xmpp-style) apps, I've written https://github.com/ge0rg/MemorizingTrustManager

  42. Ge0rG

    ralphm: right. with sufficient planning, you can have a fallback pin in the app, too ;)

  43. Wiktor

    got it

  44. jonasw

    Ge0rG, I’d have a backup cert in a secure store which the app already trusts. if cert A is comprimised, I roll out cert B on the services. App would distrust cert A once it has seen cert B in the wild.

  45. jonasw

    then I’ve got some time to roll out an update with cert B as primary and a new cert C as backup.

  46. ralphm

    jonasw: that is more or less exactly HPKP

  47. Ge0rG

    There is an easy solution: don't lose your private keys :P

  48. ralphm

    Ge0rG: thanks for your theoretical insight

  49. Ge0rG

    ralphm: I'm full of those. Ask me for more any time

  50. jonasw

    Ge0rG, ah, damn, so simple a plan! pity that *I* didn’t think of that. Maybe make that an RFC, it’s genious :)

  51. ralphm


  52. jonasw

    I wonder whether we want a way to signal in-band that an account has been deleted.

  53. jonasw

    example use-case: user A registers at foreign biboumi instance B, joins a channel and sets it to persistent. account of user A gets deleted. biboumi will forever be in that channel for no use

  54. jonasw

    idea: send <presence type="unavailable"><deleted/></presence> in response to presence probes.

  55. MattJ

    type="error" <gone/>

  56. MattJ

    Already in the RFC

  57. jonasw

    MattJ, oh

  58. jonasw

    did I say something?

  59. Holger

    But biboumi won't actively contact the JID and hence not receive that stanza error, right?

  60. Holger

    Oh "in response to presence probes". biboumi generates presence probes?

  61. Zash

    Should servers send out that to bookmarked rooms or something?

  62. Zash

    Would sorta fit with the move towards account based groupchats

  63. jonasw

    Holger, yeah, biboumi would have to poll or do something similar

  64. Holger

    That could also help affiliation list entries and nickname registrations and stuff like that.

  65. jonasw

    (or require presence subscription)

  66. moparisthebest

    Dave Cridland, DOH is only provided by a few providers and is easily blocked, plus SRV records can't contain sni/alpn info

  67. moparisthebest

    the entire point of this is to be censorship resistant, I haven't gotten down to use cases and such yet

  68. moparisthebest

    it also supports domain fronting and such

  69. Zash

    Use Tor?

  70. moparisthebest

    I hear china is pretty good at blocking tor

  71. jonasw

    I don’t think this makes a lot of sense in general use-cases.

  72. jonasw

    china is pretty good at blocking a lot of stuff, even if running via VPN.

  73. Zash

    You can't crypto your way out of *blocking*

  74. moparisthebest

    you can to a point

  75. Zash

    And is blocking equal to censorship?

  76. moparisthebest

    yes? it's designed to get around blocking

  77. moparisthebest

    and application code should be able to use the exact same logic as for xep-0368 (and kinda-posh) except a single https call instead of DNS queries

  78. moparisthebest

    it's a total hack that shouldn't exist, you can thank oppressive regimes

  79. Dave Cridland

    I don't follow why this is more resistent than DOH etc.

  80. moparisthebest

    Dave Cridland, because each xmpp server runs their own

  81. moparisthebest

    it's federated

  82. Dave Cridland

    So you just block the XMPP server IP as a whole?

  83. moparisthebest

    then the operator spins up another xmpp server someplace else

  84. Zash

    Calling everything censorship annoys me. :(

  85. moparisthebest

    also you can use tricks to make it not look like an XMPP server

  86. moparisthebest

    (you could inspect IP + User-Agent requesting this document and lie to russian govt with a 404)

  87. moparisthebest

    plus it supports domain fronting (send sni someunrelatedservice.com) and nothing else currently does

  88. Ge0rG

    Chinese VPN detection is based on traffic patterns, so even if you tunnel through https, they'll throttle you into oblivion

  89. moparisthebest

    xmpp runs pretty well on slow connections doesn't it?

  90. Zash


  91. MattJ

    It can do. I'm not entirely certain how many standard implementations handle it

  92. MattJ

    e.g. I think some clients aggressively ping the server

  93. moparisthebest

    oh thought of another reason for this, telegram is handing different server blocks to different people based on region to make IP blocking harder

  94. moparisthebest

    and you can only do that if you can afford to run your own DNS network

  95. moparisthebest

    unless it's just a page on a web server in which case any tiny xmpp server can do it

  96. Ge0rG

    how many IP blocks does a tiny xmpp server have, typically?

  97. jonasw


  98. Maranda


  99. jonasw

    something between 0 and 1 I guess

  100. Maranda

    as long as you don't take in account ipv6

  101. Ge0rG

    Maranda: how many non-consecutive IPv6 blocks do you have?

  102. Maranda

    ipv4 I got like 3 IPs, ipv6 one native, and one /48 tunneled.

  103. Ge0rG

    Maranda: 3 IPs from different ISPs?

  104. Maranda

    (on the xmpp server vps, but it does different stuff)

  105. Maranda


  106. Ge0rG

    Maranda: how do you want to get around blocking with that?

  107. Maranda

    well they're non consecutive though

  108. jonasw

    "how many blocks with different rwhois do you have?" is probably the most reasonable question in this context ;-)

  109. Maranda

    the ipv4 addresses are all from different CIDRs

  110. Ge0rG

    I've got a dozen or so IPs from my core ISP, over two different CIDRs. And I could arrange for traffic redirects on two other ASNs, more if I involve friends.

  111. Maranda

    Ge0rG, I'm not sure neither I care about blocking I just answered your ip question btw

  112. moparisthebest

    Ge0rG, well if you could aws and such, a lot

  113. Ge0rG

    moparisthebest: do the moxie dance?

  114. moparisthebest

    regardless, way more than if you have to run your own distributed global dns network

  115. moparisthebest

    Ge0rG, that's the whole point yes

  116. jonasw

    I don’t see use in that, to be honest

  117. jonasw

    it will be way too complex for any server or client to implement *with actual benefit*

  118. Maranda gives an eerie stare at XEP-0357

  119. moparisthebest

    jonasw, anything that implements 368 and http upload should be able to implement this with, ~20 lines of code max?

  120. jonasw

    moparisthebest, but there’s no benefit

  121. jonasw

    as Ge0rG said, you need quite a bit of resources (both time and money) to do the things which bring the benefit here

  122. moparisthebest

    jonasw, the benefit is evading blocks

  123. jonasw

    I am aware

  124. Ge0rG

    you can't evade blocks if all you have is one IP address.

  125. jonasw


  126. moparisthebest

    you can if they don't know it's an xmpp server, and you can for a bit

  127. moparisthebest

    then you jump to a different xmpp server

  128. jonasw

    yeah, but, who has the time resources to actually do that

  129. moparisthebest

    plus right now even big xmpp servers can't do domain fronting etc without custom clients

  130. moparisthebest

    this would enable that too

  131. Maranda

    well I added on lightwitch.org a xep 368 record for direct tls c2s on port 443, I played with port multiplexing a bit.

  132. Maranda


  133. jonasw

    yeah, 368 was simple and such, which is why it gained adoption really fast

  134. Maranda

    and noticed Conversation is actually using it.

  135. jonasw

    but this isn’t simple

  136. moparisthebest

    explain how it's any different?

  137. jonasw

    and it doesn’t bring any benefit without additional resources (time to hop IPs, and the actual IPs to hop to)

  138. Maranda

    jonasw, I'm not sure if I should consider implementing direct tls for s2s too...

  139. moparisthebest

    jonasw, it does, domain fronting

  140. jonasw

    moparisthebest, where does that still work?

  141. jonasw

    I heard google and AWS kill you if you do that

  142. moparisthebest

    if you are a huge service like signal maybe

  143. moparisthebest

    just as a future view, this is step 1 to censorship (blocking for Zash) proof xmpp

  144. moparisthebest

    other stuff we talked about is being able to keep your contact list/conversations and hop between any xmpp server you like at any time, even being able to be connected to multiple at the same time (clients would ignore jid and use a cryptographic identifier instead, servers would be unchanged)

  145. moparisthebest

    fun stuff

  146. moparisthebest

    oh also allowing contact's clients to route messages, the fun possibilities are endless

  147. jonasw

    that’s mostly stuff you talked about, which I personally find quite unneeded and overkill

  148. jonasw

    before venturing in that direction XMPP should get it’s basic sh*t together.

  149. jonasw

    we’re still losing messages (#thanksomemo)

  150. moparisthebest

    sure if you don't live in a place that is blocking secure chat apps this is entirely un-needed jonasw

  151. jonasw

    moparisthebest, a place which is blocking secure chat apps will block XMPP too when the time has come

  152. Zash

    Yeah, can we get all our shit, put it in backpack, so it's together.

  153. moparisthebest

    not if we make it impossible to block with those changes?

  154. moparisthebest

    that is after all the entire point

  155. jonasw

    that won’t make it impossible.

  156. jonasw

    only harder

  157. moparisthebest

    you only have to make it hard enough so it's not worth trying

  158. Zash

    moparisthebest: https://www.schneier.com/books/secrets_and_lies/pref.html this was a good read

  159. moparisthebest

    it looks like https, anyone can use any server, so as fast as you block them, new ones pop up and you interrupt no one

  160. Zash

    I think you need to read it

  161. jonasw

    moparisthebest, it does not look like HTTPS

  162. jonasw

    it may look like HTTPS on the byte level

  163. jonasw

    but the chinese are very godo at blocking based on patterns

  164. jonasw

    you won’t stop /that/ with your fancy stuff

  165. jonasw

    (with patterns, I mean packet sizes and timings)

  166. moparisthebest

    so it looks like any modern interactive html5 app?

  167. jonasw

    moparisthebest, not quite

  168. jonasw

    take a look at their research.

  169. jonasw

    they can detect e.g. Facebook quite certainly even through a VPN.

  170. Holger

    > being able to keep your contact list/conversations and hop between any xmpp server you like at any time, even being able to be connected to multiple at the same time (clients would ignore jid and use a cryptographic identifier instead, servers would be unchanged) Haha, sure. We fail at fixing avatars.

  171. moparisthebest

    Zash, I read this one https://www.schneier.com/books/data_and_goliath/

  172. jonasw

    my thoughts exactly, Holger

  173. moparisthebest

    that's just client-side changes though, you could make a version of conversations that did that today without anything extra required from servers

  174. moparisthebest

    it would even be backwards compatible with other clients, though not very friendly UI wise in them

  175. jonasw

    "just clients"

  176. jonasw

    because clients aren’t the main problem :)

  177. moparisthebest

    you specifically mentioned avatars which require all clients and all servers to change

  178. moparisthebest

    you'd agree changing a single client is easier right?

  179. Holger

    Well if we're just interested in a single client then the avatar issues become much easier to solve as well.

  180. Holger

    Whatever. Just implement it if it's so simple?

  181. moparisthebest

    I plan to

  182. Holger


  183. moparisthebest

    I don't really write specs without implementations

  184. moparisthebest

    usually the implementations come first, I think that makes me a bad programmer, oh well :)

  185. Zash

    I think you wanna write specs and implement at roughly the same time

  186. MattJ


  187. Zash

    Maybe think real hard about requirements first.

  188. Zash

    But all that goes out the window when you start implement anyways

  189. MattJ

    I don't think I've ever seen a pre-written spec survive an implementation unscathed

  190. Ge0rG

    > clients would ignore jid and use a cryptographic identifier instead Congratulations, you just combined the drawbacks of XMPP with the drawbacks of p2p systems and the drawbacks of mixnets

  191. moparisthebest

    I looked at it the other way, benefits if p2p systems plus benefits of XMPP

  192. Ge0rG

    moparisthebest: what's the benefit of XMPP once you replace JID-based routing with crypto identifiers?

  193. Ge0rG

    Why not XEP-0174 over .onion nodes?

  194. Zash

    Why not normal xmpp over .onion?

  195. moparisthebest

    Ge0rG, routing is still jid-based, clients just collapse multiple JIDs using the same crypto identifier under one 'contact'

  196. moparisthebest

    and the benefit is still all the other things xmpp provides, one of the biggest being it's mobile-battery-friendly

  197. Ge0rG

    moparisthebest: how do you tell your buddies about your new JID if they also just switched JIDs because of blocking?

  198. jonasw

    I don’t even want to think how that works with MAM queries

  199. jonasw

    or MUCs.

  200. jonasw

    or anything non-trivial really

  201. Ge0rG

    moparisthebest: you just invented a crypto-overlay network over XMPP.

  202. moparisthebest

    right that's exactly what it will be

  203. Ge0rG

    moparisthebest: but WHY?

  204. moparisthebest

    fun and censorship resistance? :P

  205. jonasw

    for certain definitions of fun

  206. jonasw

    not to kinkshame, but I’m not into that I think

  207. Ge0rG

    moparisthebest: it won't get you censorship resistance.

  208. Ge0rG

    moparisthebest: because once your server is censored, you have no way to find out the new identity of your friends

  209. moparisthebest

    I guess that is a problem if you both switch at the same time

  210. moparisthebest

    DHT over XMPP ?

  211. Ge0rG

    why use xmpp if you can have QUANTUM BLOCKCHAIN TECHNOLOGY!

  212. MattJ


  213. MattJ

    in particular https://wiki.xmpp.org/web/Secure_Distributed_JID_Discovery#DHT_Based_Solution

  214. moparisthebest


  215. moparisthebest

    verification would be solved since the identifier is a cryptographic key anyway

  216. MattJ

    Discussion at https://mail.jabber.org/pipermail/standards/2013-February/027036.html

  217. Ge0rG

    Open Problems: 1. How to prevent impersonating other users.

  218. moparisthebest

    solved by crypto already

  219. Ge0rG

    moparisthebest: Zooko called, and he wants his triangle back.

  220. moparisthebest

    that's a problem *there* because you want to prove a certain jid has a certain phone number

  221. moparisthebest

    my thing would only want to prove a certain jid has control of a certain cryptographic key, which of course is super easy to prove

  222. Ge0rG

    for certain values of "super easy"

  223. Ge0rG

    moparisthebest: my point is: the XMPP model is not suited for what you want.

  224. moparisthebest

    I don't know why you'd invent something else to give you everything XMPP does when you can just overlay it?

  225. Ge0rG

    moparisthebest: because you'll end up with a system that combines the drawbacks of xmpp with... we've been here already.

  226. MattJ

    I'm on both sides :)

  227. MattJ

    If you're going to make such a system, using XMPP as a foundation buys you a lot

  228. MattJ

    It would of course be quite different to what we have today, I don't think sane interop can be expected

  229. Ge0rG

    I want to see a list of reasons, not some hand-waving of how great xmpp is.

  230. Ge0rG

    Okay, thanks. That's a reasonable response.

  231. MattJ

    <-- fixing production issues

  232. jonasw tired

  233. Maranda

    okay let's see if direct tls for s2s causes a meltdown...

  234. Maranda will need to restart the server anyways.

  235. jonasw

    is there any s2s implementation of it?

  236. moparisthebest

    jonasw, I think zinid said latest ejabberd supports it

  237. moparisthebest

    plus metre

  238. Maranda

    Oh Metre does it?

  239. Maranda just finished implementing it in Metronome

  240. Maranda

    tested it with ejabberd

  241. Maranda

    let's see Metre

  242. Maranda grabs dave.cridland.net :P

  243. moparisthebest

    Isn't metronome a prosody fork? How hard would it be to patch prosody the same way Maranda ?

  244. Maranda

    I'm not entirely sure, my knowledge of Prosody's codebase sort of stilled at around 0.9 tbh 🤣

  245. Maranda

    But I suppose "not much"

  246. moparisthebest

    Do you support SNI and alpn too ? (For outgoing connections?)

  247. Maranda


  248. moparisthebest

    Not even SNI? That's a must

  249. Maranda

    moparisthebest, nai and luasec 0.5/0.6 which are the most common around don't support SNI anyways

  250. Zash

    moparisthebest: No need, the unencrypted stream header has it.

  251. moparisthebest

    2005 called and wants it's TLS extensions implemented

  252. Zash

    LuaSec has had SNI a long time FWIW

  253. Maranda

    at least I'm sure LuaSec 0.5 doesn't support it

  254. moparisthebest

    Just make sure you fall back on cert errors

  255. Maranda lookies.

  256. Maranda

    nope doesn't