XSF Discussion - 2014-01-16

  1. dwd has left
  2. tato has left
  3. waqas has left
  4. Lance has joined
  5. bear has left
  6. waqas has joined
  7. emcho has joined
  8. emcho has left
  9. emcho has joined
  10. waqas has left
  11. waqas has joined
  12. bear has joined
  13. emcho has left
  14. emcho has joined
  15. waqas has left
  16. waqas has joined
  17. emcho has left
  18. emcho has joined
  19. emcho has left
  20. emcho has joined
  21. emcho has left
  22. emcho has joined
  23. emcho has left
  24. emcho has joined
  25. Jef has left
  26. emcho has left
  27. emcho has joined
  28. Lance has joined
  29. emcho has left
  30. emcho has joined
  31. bear has left
  32. emcho has left
  33. emcho has joined
  34. emcho has left
  35. emcho has joined
  36. emcho has left
  37. emcho has joined
  38. Lance has left
  39. emcho has left
  40. emcho has joined
  41. emcho has left
  42. emcho has joined
  43. emcho has left
  44. emcho has joined
  45. emcho has left
  46. emcho has joined
  47. waqas has left
  48. Steffen Larsen has joined
  49. Steffen Larsen has left
  50. Steffen Larsen has joined
  51. SouL has joined
  52. Steffen Larsen has left
  53. simon has joined
  54. emcho has left
  55. emcho has joined
  56. Steffen Larsen has joined
  57. dwd has joined
  58. emcho has left
  59. emcho has joined
  60. Steffen Larsen has joined
  61. Alex has joined
  62. Lloyd has joined
  63. Ash has joined
  64. dwd has left
  65. Steffen Larsen hey Guys. Just want to hear if its ok to book a hotel room for one of my friends though the discount?.. Do we have enough for everybody then?
  66. SouL has left
  67. Kev If they're attending the summit I don't see why not.
  68. Kev If they're not, it seems more dodgy.
  69. Steffen Larsen he is not XSF.. and cant make it to the summit. He'll be there for FOSDEM
  70. Steffen Larsen Kev: thats alright
  71. Steffen Larsen Kev: No problem
  72. Kev I didn't give an answer.
  73. Steffen Larsen Ohh I thought you said it was dodgy
  74. Kev I'd see what Dave/Ralph say :)
  75. Steffen Larsen what that ever means
  76. Kev Dodgy/uncertain.
  77. Steffen Larsen ;-)
  78. Steffen Larsen Ok
  79. Steffen Larsen just wanted to hear your oppion
  80. Kev I think there are people going just for the summit, so in practical terms if he's going just for FOSDEM, it sounds like there should be rooms.
  81. Steffen Larsen Kev: so its ok to give him them link?
  82. Kev See what Dave/Ralph think.
  83. Kev I have no authority here :)
  84. Steffen Larsen Kev: Thanks!
  85. FloRida has joined
  86. FloRida has left
  87. FloRida has joined
  88. FloRida has left
  89. FloRida has joined
  90. dwd has joined
  91. FloRida has left
  92. dwd Steffen Larsen, I'm not against using our discount for people not attending the summit, if they're XMPP related folk. If they aren't at all, then I don't mind them using the discount *later* - after most people are booked.
  93. Steffen Larsen dwd: ok thats all fair.
  94. dwd http://www.keepcalm-o-matic.co.uk/p/keep-calm-and-encrypt-your-im/ anyone?
  95. Steffen Larsen dwd: The guys is a sysadm. - one of my friends.. not directly XMPP related. So I guess I wait untill all have booked
  96. Steffen Larsen dwd: Dave, how do we/I know when all people have booked?
  97. dwd Steffen Larsen, We don't. :-) Florian can watch the numbers though.
  98. Steffen Larsen dwd: ohhh..
  99. dwd Steffen Larsen, Using the entire block is actually a good thing; gives us more bargaining power next year.
  100. Steffen Larsen dwd: true true
  101. dwd Steffen Larsen, And of course it doesn't cost the XSF anything.
  102. Steffen Larsen dwd: even better
  103. Steffen Larsen dwd: BTW what did we agree about the dinner? was it saturday or?
  104. dwd Saturday, usual place and rules.
  105. ralphm Steffen Larsen: you mean you don't read the logs here?
  106. dwd So XSF Members and XSF Dinner sponsors only.
  107. Steffen Larsen cool
  108. emcho has left
  109. emcho has joined
  110. Steffen Larsen ralphm: sorry no
  111. Steffen Larsen dwd: yes i know
  112. simon .
  113. simon oops
  114. emcho has left
  115. emcho has joined
  116. intosi dwd: keep calm and order those shirts ;)
  117. SouL has joined
  118. ralphm keep calm and federate?
  119. ralphm hmm
  120. dwd ralphm, Yeah, it's not quite right, I agree.
  121. emcho has left
  122. ralphm http://www.keepcalm-o-matic.co.uk/p/keep-calm-and-federate--1/
  123. ralphm (I'm spending too much time in inkscape these days, it seems)
  124. SouL has left
  125. SouL has joined
  126. dwd Keep Calm and Use XMPP might work better with the lightbulb. (Or Use Jabber, mind)
  128. Kev Just to check, we don't feel that Keep Calm And... has been overdone as a meme, do we?
  129. dwd I want to play the security card a lot, because this seems to be the right bandwagon to jump on (and we have a legitimate claim to a seat on this bandwagon)
  130. Kev I keep having ideas like "Let's chat about trusting servers" pop into my head, but I don't think they really tell the story.
  131. dwd "Trust your provider. Host IM yourself." or something?
  132. Kev I'm thinking along those lines.
  133. Kev Or "Keep Jabbering with those you trust" or ... something.
  134. dwd Kev, I think, BTW, that the meme has been so overdone it's almost meta.
  135. Steffen Larsen "Talk about federated security"..
  136. intosi In TLS we trust
  137. Steffen Larsen ha ha
  138. ralphm dwd: I do think that ... and encrypt your IM works for FOSDEM
  139. dwd I'm reminded about that quote of Woddy Allen's quote about masturbation - "Don't knock it, it's sex with someone you really love."
  140. Kev Haha
  141. Kev "We trust in the Federation"
  142. Kev I've made myself giggle :)
  143. ralphm but people might think that we mean e2e
  144. intosi dwd: classic Woody
  145. Kev Why does no-one like my Star Trek joke? I don't believe for a moment that you're not sufficiently nerdy :p
  146. dwd Kev, Other than I did "Federation: Not just for Star Trek" a year or two back?
  147. ralphm http://www.juxtapost.com/site/permlink/b15477f0-f5df-11e1-8de6-fba9fc1c5f14/post/bye_bye_robot_poster_the_federation_needs_you/
  148. Kev dwd: I don't remember that at all.
  149. ralphm I do
  150. dwd My wife is suggesting singing "I'm XMPPY, I'm XMPPY, I know I am - I'm sure I am - I'm XMPPY!"
  151. ralphm I'd be happy to reserve a slot for her at the Lounge.
  152. ralphm Live entertainment is something we didn't do much about, still
  153. dwd (She also suggests a school choir singing it. Obviously well in-tune with current tech thinking)
  154. Steffen Larsen wow that could be cool
  155. ralphm Perfect. Let me know which day/time.
  156. FloRida has joined
  157. FloRida has left
  158. FloRida has joined
  159. Steffen Larsen has left
  160. FloRida has left
  161. Steffen Larsen has joined
  162. Steffen Larsen has left
  163. simon has left
  164. simon has joined
  165. Jef has joined
  166. simon has left
  167. simon has joined
  168. Ash Just thinking about the encryption stuff - I think we need to be a little careful with the message as there may be a number of people (especially hardcore techies) in the 'you mean you weren't already?' camp.
  169. MattJ *nod*
  170. MattJ That has crossed my mind a few times, but actually I haven't seen anyone react that way yet
  171. winfried has joined
  172. Ash I think it's just something to be sensitive to
  173. MattJ After all, the web is far less encrypted than XMPP is
  174. Ash Exactly
  175. intosi As is email.
  176. Ash We just need to make sure the message is positive
  177. simon and in the background get our house in order.
  178. dwd Ash, I think we need to ensure we're being honest, open, and seeking improvement.
  179. winfried And the message is: "we are raising the bar even further and making sure it works" ;-)
  180. simon basically it comes down to good configuration (not lazy about certs / DNS etc) rather than something inherently wrong with XMPP's core design.
  181. Ash dwd: I'm not saying we shouldn't be honest, but we just need to make sure the message has the right spin on it.
  182. simon and keep pointing people to xmpp.net to test their sit.
  183. simon site
  184. Ash simon and winfried: definitely :)
  185. dwd simon, RIght. We can discuss how we've held strong-auth interop tests (including CRLs etc) several years back; it's now a case of ensuring deployment, not even implementation.
  186. dwd makes mental note to ensure the XSF's interop work a couple of years back gets noted in PSA's STRINT draft.
  187. emcho has joined
  188. Ash Definitely. I was just worried that people might hear the message as 'we're starting to encrypt communications' rather than 'we're phasing out unencrypted communications'.
  189. winfried @Ash: it more like: "We are phasing out all but the most secure configurations" ;-)
  190. Ash even better!
  191. fippo winfried: well, we're not able to enforce authentication... so i don't think saying this is a good idea
  192. simon Geez - winifried is an excellent marketer. I'm nominating him to write xmpp.org content.
  193. ralphm simon: who are you?
  194. simon ralphm - I believe we've met at the odd XMPP event before.
  195. ralphm How can I be sure it's you?
  196. intosi Because Simon says… he's Simon.
  197. intosi That's how you play the game.
  198. simon until xmpp.org does cert verification or DANE, you can't.
  199. dwd simon, That won't help.
  200. ralphm simon: using anonymous.jabbix.com is the other extreme, though
  201. simon short of using corkscrew and some socks5 tunneling, I'm behind a crappy corp fw.
  202. dwd simon, That's what 3G is for. :-)
  203. kevin has joined
  204. simon what's the preferred XMPP client on android these days?
  205. dwd xabber doesn't work on newish Prosody, but jTalk might be OK.
  206. ralphm I want to say Xabber, but I can't use it
  207. MattJ Yaxim, but it doesn't do MUC yet
  208. MattJ dwd, it doesn't? Why?
  209. dwd MattJ, Because it breaks.
  210. ralphm (because it has some issues and development seems stalled or at least invisible)
  211. MattJ Yaxim is actively developed, supports XEP-0198 and Carbons
  212. ralphm https://github.com/redsolution/xabber-android/issues/264
  213. MattJ Completely open-source, and MUC is coming soon
  214. MattJ ralphm, nice
  215. MattJ it doesn't work on "newish Prosody"? I don't think we've ever had a release that would accept unescaped ampersands...
  216. ralphm MattJ: I don't think this particular bug is something related to Prosody at all
  217. ralphm MattJ: I did a c2s tcpdump for it, and decoded it with my server's key
  218. MattJ Fancy
  219. winfried fippo, you are right, we can't centrally 'phase out' anything in the XMPP network, but the current campaign is as close as we can get
  220. ralphm I suppose in the future you can't do that anymore, right?
  221. ralphm In any case, I would not go as far as calling XMPP secure, as it has many facets
  222. winfried :-) temporally disable FS
  223. ralphm winfried: I assume in the future, clients will require that?
  224. winfried point taken
  225. Ash I though the idea was to create a 'jabber' network of public xmpp servers which enforced encryption. i.e. you can run an xmpp server and do whatever you like, but to interface with the 'jabber' network you need to enforce encryption rules. Although I may have missed a whole bunch of discussion somewhere.
  226. simon phasing out is perhaps the wrong way to view it. But being able to connect to some servers will mean you need to get your own server configured correctly.
  227. ralphm so anyway, besides heckling simon a bit, I agree with Ash' earlier point
  228. simon buddycloud.org /com already reject servers with invalid certs.
  229. ralphm simon: and without encryption, too?
  230. simon :) no - all s2s is encrypted.
  231. ralphm so you can't use your imaginator.com address
  232. simon that's still google :) but the new buddycloud server uses DNS discovery so you can run one alongside a google apps domain #thanks-lloyd.
  233. ralphm simon: yeah, I knew that the domain was with Google
  234. ralphm simon: what, you mean you have two different servers listening for the same domain and you use some DNS trickery to make buddycloud choose the non-google one?
  235. Ash Buddycloud is magic!
  236. ralphm magic is cool, but I hope I misunderstood
  237. fippo there is a difference between encryption and authenticated encryption in terms a what attacks it protects you against
  238. dwd To be fair, BTNS mitigates a set of attacks that are a proper subset of those mitigated by authenticated encryption.
  239. Lloyd ralphm: buddycloud server still does disco lookups, but if there's a specific SRV record it'll use the result of that to direct it to the other server. No magic - magic sucks.
  240. ralphm It still seems a bad idea to have two different servers at the same address
  241. ralphm I.e. if this is a special case for servers that are not up-to-spec (like Google's), I don't like it at all
  242. ralphm If I misunderstood, please elaborate, though.
  243. dwd It suggests there's no commonality between a buddycloud server and an XMPP server, at least.
  244. Lloyd Its a special case for people who can't install a buddycloud component on their xmpp setup
  245. Lloyd so we run another xmpp server with the buddycloud component connected and use that
  246. Steffen Larsen has joined
  247. ralphm Lloyd: While I admire that stand point, it seems to me that this solution breaks the network.
  248. simon how does it break the network?
  249. ralphm By connecting to other servers based on something outside of the XMPP realm itself
  250. dwd simon, You're offering XMPP based services using a protocol that's no longer interoperable with XMPP?
  251. simon Using XMPP to exchange data between components is breaking network? I must have misread a XEP somewhere.
  252. stpeter has joined
  253. dwd simon, Well, it sort of depends on whether you're thinking that introducing a new SRV records etc is actually still XMPP. An unmodified XMPP server wouldn't connect, right?
  254. Lloyd The server isn't modified at all. I think maybe something has been lost in the text description.
  255. MattJ What does the SRV lookup?
  256. MattJ (for the buddycloud discovery)
  257. Lloyd the buddycloud component. It still uses DISCO however.
  258. Lloyd Yes exactly
  259. ralphm So when is the SRV thing happening and why?
  260. intosi And what will it actually try to resolve?
  261. Lloyd If I do disco against imaginator.com and see there's no buddycloud component I do an SRV record check which tells me that there's a buddycloud component sitting at channels.imaginator.com and to talk to that.
  262. simon buddycloud runs as a component and components talk to eachother using XMPP. buddycloud components can optionally fall back to using a SRV lookup in the case of a domain not running their own XMPP server.
  263. ralphm As I said, I want to be wrong about this and would be happy if buddycloud is pure XMPP
  264. Lloyd channels.imaginator.com is still running as a component on an xmpp server.
  265. Kev Lloyd: So what you're actually saying isn't anything about SRV. Just that even if there's no advertised service, it'll try to connect on a default domain as if it had been advertised?
  266. ralphm So it is really a fallback on channels.domain
  267. simon IMHO, the notion that I have to do everything to do with one domain through one server is a wrong assumption. Far better to use DNS delegate services for domains than bottleneck everything through a single server (or cluster).
  268. Lloyd ralphm yes, disco+ so to speak (probably a *really* bad term)
  269. Kev simon: There's nothing that suggests that you should be using one server for everything.
  270. Lloyd kev it'll try and connect on domain anyway, if no advertised service will see if there's a DNS hint.
  271. ralphm simon: you may disagree and actually implement things in the background, but just doing something else entirely protocol-wise doesn't seem proper
  272. Lloyd if there's no dns hint, well other service doesn't run buddycloud :)
  273. simon Kev: my understanding too.
  274. Kev blah.doomsong.co.uk could be on the moon, and have no link to doomsong.co.uk other than S2S.
  275. ralphm I understand that you have to work around servers (like Google's) that you can insert disco records on
  276. simon Ralphm: not sure I really understand your concern.
  277. Kev simon: Because you're making something simple sound like you're re-inventing the wheel.
  278. ralphm simon: well, the description of what was happening initially sounded really horrible
  279. Kev If you said "If there isn't a service in disco for the domain, we'll try channels.domain anyway" it would be much less scary.
  280. ralphm simon: now I understand better I'm milder in my judgement
  281. Kev Misleading is the enemy of good, and all that.
  282. simon Don't think I claimed that this was rocket science. Just a nice way to host instances outside of their XMPP domain.
  283. Steffen Larsen has left
  284. Steffen Larsen has joined
  285. fsteinel has joined
  286. Lloyd *ahem* "maybe something has been lost in the text description" …. or gained as the case may be :)
  287. ralphm simon: arguably, nothing in XMPP is rocket science. But I dread having incompatible systems referred to as XMPP
  288. ralphm like, say, whatsapp
  289. MattJ ralphm, I think by your definition, if you haven't been following Buddycloud, it took that route long ago
  290. MattJ It uses XMPP purely as a transport mechanism nowadays
  291. ralphm MattJ: I haven't followed it closely, true, and I knew there was a mechanism for finding servers if you're on a hosted service, but the description of doing something else because of a special SRV record sounded really bad
  292. ralphm MattJ: turns out it has nothing to do with SRV in principle
  293. Steffen Larsen has left
  294. simon ralphm: bc is designed to run as a component on any XMPP server that understands 114. Finding other servers can be done using disco for the corresponding remote component. This DNS discovery is used in the situation that there isn't a buddycloud component discovered.
  295. ralphm isn't that what I said?
  296. ralphm the initial explanation was worse
  297. ralphm and also, what if there is no SRV record for channels.domain but there's a server listening on port 5269? Does that work?
  298. intosi You mean on the A or AAAA record listed for channel.domain?
  299. ralphm yes
  300. Lloyd ralphm: yes, standard disco is the preference, DNS is the fallback
  301. ralphm see this is the confusing bit
  302. intosi So, normal 6120 §3.2 behaviour?
  303. ralphm if you say 'channels.' is the fallback, *then* it is clear
  304. ralphm You don't need to talk about DNS in the case, even though it is involved
  305. simon it falls back to looking for a SRV record - if that isn't there then it gives up.
  306. ralphm so that's unlike normal lookup for s2s
  307. Zash has joined
  308. simon who said it was s2s.
  309. intosi Well, that's what you were implying earlier, as I understood it.
  310. Kev You did, implicitly, when you said you were doing standard XMPP.
  311. simon component to component if you want to name it.
  312. Kev There is no XMPP component to component protocol.
  313. MattJ component1->server1->server2->component2
  314. Kev So, S2S, then.
  315. simon thanks MattJ.
  316. simon So if there's a XEP that says how components should be delegated, I'd love to see it.
  317. ralphm XEP-0114 is a server side protocol, totally irrelevant for inter server communication in any sense
  318. simon but since there isn't I don't think applying the entire s2s stack to discovery makes sense.
  319. fsteinel has left
  320. ralphm the entire s2s stack isn't much is it
  321. ralphm it is setting up streams between servers
  322. ralphm Note that I am trying to be very exact here
  323. Kev simon: A component is, to the outside world, just another server.
  324. ralphm while Google is one big distributed beast posing as many servers
  325. simon why would a buddycloud component need care about s2s if it knows what remote component to talk to? All it cares about is discovering the remote component and connecting to the right XMPP server.
  326. ralphm s2s-wise you can't tell the diff
  327. Kev simon: It doesn't talk to a component. It talks to a server.
  328. ralphm simon: I don't care how buddycloud's organised internally
  329. ralphm I only care about the edges, in this case s2s
  330. ralphm Similarly, protocol-wise, there's nothing to prevent having MUC rooms and user accounts at the same domain
  331. ralphm (say, ralphm@jabber.org and jdev@jabber.org)
  332. MattJ Prosody allows it :)
  333. simon ralphm:so if a domain doesn't have a buddycloud server (perhaps it's hosted on bc-hosting-cloud.org - how should the lookup work?
  334. ralphm apparently 'try channels.bc-hosting-cloud.org' instead
  335. ralphm without any additional changes
  336. simon really?
  337. ralphm I assume you know how it works
  338. simon that seems to do away with a lot of the correctness of using SRV to say this is the service that runs X.
  339. ralphm wat?
  340. ralphm once you are ready to try channels.domain, you try dns srv, if missing dns a and aaaa and [ort 5269
  341. ralphm like s2s always does?
  342. waqas has joined
  343. simon you are assuming that you know the name of the remote component running buddycloud. If I want to follow ralphm-on-buddycloud@ik.nu, (and ik.nu doesn't run a buddycloud server) my buddycloud component now has to assume that all buddycloud servers are channels.ik.nu.
  344. intosi Sure.
  345. simon correction that the remote server is channels.ik.nu
  346. intosi Then try the hosts and ports for s2s as per 6120 §§ 3.2.1 – 3.2.2.
  347. simon why would it try channels.ik.nu and not other-service-name.ik.nu?
  348. simon remember if you user@domain.com on buddycloud not user@buddycloud-component.domain.com
  349. simon https://github.com/buddycloud/buddycloud-xep/blob/master/buddycloud.xml#L483
  350. simon (XEPign now)
  351. intosi simon: because you just defined it would, if no other service was disco'd on ik.nu
  352. simon fair enough. I just don't think it's a great idea to hardcode expected hostnames into code.
  353. kevin has left
  354. simon it's not like we expect to connect to XMPP.domain.com as a fallback for discovery.
  355. intosi simon, you misunderstood. You're defining a fallback for your BC disco.
  356. intosi As far as I understand, you defined this as channels.domain
  357. simon I explained that you don't know the component on the remote server that offers buddycloud services.
  358. emcho has left
  359. emcho has joined
  360. simon Does this help http://imgur.com/4y2BTvd ?
  361. intosi Exactly how does DNS lookup say it should talk to channels.capulet.lit in this case, and which part of this diagram is resolving it? Meaning: what DNS query is made? Is this happening in the buddycloud component, and will that component use the found name in a regular fashion, that is: ask montague.lit to route it to whatever is discovered?
  362. simon _buddycloud-server._tcp.imaginator.com. (code for the curious: https://github.com/buddycloud/buddycloud-server-java/pull/114)
  363. ralphm simon: now it is clear. Thanks.
  364. simon ralphm: :)
  365. ralphm simon: I'm not sure why it took this long to get to this :-(
  366. intosi You should've pointed to this commit immediately. Would've saved a lot of discussion.
  367. ralphm simon: I also think this was the feared answer
  368. ralphm I do like some parts of this solution (the indirection), but not the fact that it is done as a SRV record pointing to a server that talks (some form of) XMPP
  369. Zash How does that work with IDNA?
  370. intosi A PTR would be better suited, a la DNS-SD
  371. fsteinel has joined
  372. waqas Without DNSSEC (and we'll be without DNSSEC for a while), isn't relying on DNS for this insecure?
  373. fsteinel has left
  374. fsteinel has joined
  375. ralphm intosi: agreed. DNS-SD is great for this
  376. ralphm waqas: I wanted to leave DNSSEC out of this particular discussion
  377. ralphm it is rather orthogonal
  378. MattJ (but it is insecure ;) )
  379. ralphm MattJ: what ever, man
  380. waqas Well, there is no trust here if there's a third-party able to send DNS responses to the client
  381. intosi MattJ: live a litte. On the edge, man!
  382. ralphm waqas: the same thing happens with normal s2s or c2s traffic. We're talking about how buddycloud solves a particular discovery mechanism for servers that you don't control, but you do 'control' the DNS
  383. waqas ralphm: That's not true, in normal s2s or c2s traffic, assuming TLS is in effect and certs are verified, you can't pretend to be someone you are not. In this case, the entire trust model is only DNS, nothing else.
  384. waqas ralphm: So if I as an attacker can hack DNS, should I be able to pretend to be the buddycloud server of any arbitrary user?
  385. simon ralphm: "SRV record pointing to a server that talks (some form of) XMPP": once you have discovered the remote bc component, you are using the s2s connection between the two xmpp servers. We can debate the inscurity of the DNS system if you want but it seems that the road to solving that is well defined with DNSSEC deployment.
  386. ralphm waqas: in this implementation, yes. If he used PTR records, it would be better
  387. ralphm simon: no, because the discovery doesn't do fallback on A/AAAA records
  388. simon how is fallback magically secure?
  389. ralphm simon: intosi is right in saying you should have used PTR here. Then, you'd point to the domain where a service is hosted, and then do the *normal* s2s stuff
  390. ralphm (the key here is *domain* v.s. server)
  391. waqas My point is that at no point is the original server asked over a secure channel whether the buddycloud server is valid for that host. I'd much prefer e.g., a POSH like approach where the discovery is over https, not insecure DNS
  392. ralphm waqas: yes, that can't happen for something like Google Talk
  393. Zash waqas: Because in this scenario that server does not support that
  394. ralphm waqas: that's why it is there to begin with
  395. intosi For sane servers, this isn't needed at all.
  396. ralphm POSH is an alternative, sure
  397. waqas So.. is there a server which gets to be /the/ gtalk buddycloud server?
  398. waqas I don't see how this solves the gtalk issue, gtalk isn't going to change their DNS
  399. ralphm waqas: if you host your domain at google
  400. ralphm waqas: you control your own DNS, but not the server implementation
  401. ralphm waqas: so you can't rely on disco
  402. waqas Ah, I see, in which case you can do POSH too, no?
  403. ralphm waqas: yes
  404. waqas And POSH in that case would be secure, as opposed to DNS? :)
  405. waqas Anyway, I'm dragging this on, ignore me
  406. emcho has left
  407. simon waqas: imho the correct solution is for the XMPP community to make a concerted effort on getting good DNSSEC support in all servers (I like Proosdy's progress on this).
  408. waqas POSH will remain much easier for quite a few years I think
  409. ralphm simon: that still makes your solution suboptimal
  410. ralphm waqas: I think that it would be good enough if you did PTR records and have proper certs at the server being pointed too
  411. fsteinel has left
  412. ralphm (-o)
  413. simon If your DNS is poisoned, how does PTR help over SRV?
  414. waqas Indeed, I don't see how PTR is any more secure
  415. ralphm I am not talking about DNS poisoning. It is orthogonal to SRV being a bad choice for pointing buddycloud to another domain
  416. ralphm which was the discussion originally
  417. intosi waqas: it's not about being more secure, it's about using the appropriate record the the job.
  418. waqas Ah, k
  419. ralphm Yes, POSH or DNSSEC would make the whole thing more trusted. But just for this particular problem, having an DNS PTR (even if the DNS might be compromised) with proper certs at the endpoint is good enough, I think.
  420. waqas ralphm: From a security perspective, or without considering security?
  421. ralphm from a security perspective
  422. waqas Certs being proper does nothing to establish that serverA trusts serverB with this service
  423. simon Side note: by using PTR, the local buddycloud component must go through a bunch more roundtrips for disco-ing the right component.
  424. intosi simon: no. The component will just use the name returned and use that as the remote component domain.
  425. dwd I'm confused still. So the SRV is looked up, and returns IN SRV 5 0 5269 buddycloud.imaginator.com, right?
  426. intosi The XMPP server the component is connected to will route it.
  427. dwd What does the local component route to here?
  428. ralphm dwd: no the actual machine
  429. ralphm dwd: so, say, 'spock.imaginator.com'
  430. ralphm I'm not sure which domain is used within XMPP at that point, by the way
  431. dwd ralphm, I'm using the example on the pull request.
  432. dwd ralphm, Exactly. Does the component use "buddycloud.imaginator.com", and therefore that *too* has SRV records, this time for xmpp-server?
  433. intosi If you want to use it as an alternative to disco, that's the only way it should work.
  434. dwd OK, but what do the port numbers mean? ANd what's the handling for multiple SRV?
  435. intosi dwd: that's why I suggested SRV was the wrong record, and PTR should be used instead.
  436. Zash There's also a URI records somewhere
  437. dwd Zash, NAPTR? Yay!
  438. dwd Zash, Actually the URI variant is U-NAPTR, pronounced "Unapointer", a bit like the Unabomber, and almost as scary.
  439. intosi :)
  440. Lloyd has left
  441. intosi And again introduces priority and weight.
  442. intosi Although it's probably more appropriate than using SRV.
  443. dwd intosi, Anything other than CNAME will have some case of multiple records.
  444. dwd intosi, CNAME, mind, seems like a reasonable option.
  445. Zash dwd: I was thinking of https://tools.ietf.org/html/draft-faltstrom-uri-06
  446. intosi Could be.
  447. intosi CNAME or PTR are both more appropriate for this than SRV.
  448. ralphm I also assume that 'buddycloud' is not a registered service at IANA. I don't recall if PTR has that restriction.
  449. ralphm but SRV does
  450. intosi Although resolvers might try to get the A or AAAA of a CNAME automatically.
  451. FloRida has joined
  452. FloRida has left
  453. intosi ^resolvers^resolver libraries
  454. kevin has joined
  455. simon buddycloud-api is registered with IANA. If needed, a SRV could be. (https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=buddycloud)
  456. ralphm ah, cool
  457. ralphm simon: but I would definitely switch to something based on PTR
  458. ralphm or at least not using SRV like it is now
  459. simon (buddycloud-api is used by mobile clients needing to find the HTTP endpoint for API calls)
  460. ralphm does *that* use PTR?
  461. dwd TXT by the looks of things.
  462. intosi I'd say a U-NAPTR would be more appropriate ;)
  463. simon ralphm: TXT as defined in the DNS-SD RFC https://groups.google.com/d/msg/buddycloud-dev/ww0yjdwRuNY/Qf7930KxG7MJ
  464. dwd Ah, the iPod RFC.
  465. ralphm dwd: hah!
  466. simon The format actually makes a lot of sense for describing how to connect to remote services.
  467. dwd You've read it too, huh?
  468. dwd simon, Yes, it's a sane protocol. Just a real shame that it didn't go through the IETF standards process, and most of the edits seemed to be updating Apple product names.
  469. simon They had working implementations before writing the spec. Shocker!
  470. dwd Yes... So?
  471. simon dwd: looks like it is going through ietf https://tools.ietf.org/html/rfc6763
  472. dwd simon, Oh, so it did eventually go through standards track. It was originally going to be Informational. But the Appendix G, "All Apple product names I can think of" is still there.
  473. ralphm simon: I like implementations before writing specs. I don't like reinventing stuff that already has established solutions. Apple is notorious for just doing whatever pleases them.
  474. simon IMHO it's a good spec. Don't know why we're talking about Apple here.
  475. dwd simon, The IETF developed Zeroconf and a slew of supporting tech, and Apple developed DNS-SD instead. And eventually specified it with Appendix G.
  476. dwd simon, Most of the edits to the spec for the past few years were to update various Apple product names in Appendix G, and not to do anything else with the protocol.
  477. dwd simon, Any changes were rejected because they'd already deployed, of course.
  478. dwd simon, I agree that DNS-SD is a good spec. So was Zeroconf, but Apple effectively destroyed that one.
  479. Lance has joined
  480. ralphm dwd: hm? I thought DNS-SD built on Zeroconf, I don't know the history much
  481. dwd No, parallel development. Apple was involved in both IIRC.
  482. dwd They're *very* similar.
  483. ralphm oh
  484. simon dwd: you mean the old link local name resolution drafts?
  485. ralphm I can't make out the difference from the wikipedia page
  486. simon "local link multicast name resolution"
  487. dwd The differences are small but incompatible, according to Appendix G.
  488. ralphm oh, but that's Microsoft's stuff, right?
  489. Zash Yeah, isn't there a Microsoft one too
  490. ralphm LLMNR, what simon mentioned
  491. Zash Which one is mDNSSD then?
  492. ralphm mDNS an DNS-SD are two things
  493. ralphm mDNS is for doing DNS on lans
  494. ralphm with .local
  495. Zash and multicast
  496. Zash right
  497. ralphm hence the m
  498. simon seems like there was a lot of unhappiness about the Link Local Multicast Name stuff: http://www.ietf.org/mail-archive/web/ietf/current/msg37393.html
  499. ralphm I so wish that more things supported mDNS and DNS-SD
  500. ralphm So happy that my Ubuntu laptop can find my printer at officejet.local
  501. ralphm Unfortunately, support in Android is non-existant
  502. ralphm I SSH between my boxes at home with .local addresses exclusively
  503. simon Android music strategy is currently "send everything over bluetooth" which seems rather daft.
  504. ralphm wait huh?
  505. simon unless I missed a new app that lets me stream to my raspberryPi via wifi.
  506. ralphm I use ChromeCast, but yes, that space is still a bit of a mess
  507. simon (ralphm: one thing that Zeroconf solved nicely on the Apple side was announcing music recivers via Bonjour/Zeroconf/mDNS)
  508. ralphm although UPnP also builds on stuff like zeroconf/mDNS/DNS-SD
  509. Zash UPnP, the SOAP-over-HTTP-over-UDP thing?
  510. ralphm simon: indeed, my Rhythmbox announces itself as Ralphonics and Apple devices can play from it
  511. ralphm visa versa is horrible because of Digital Restrictions
  512. ralphm Zash: soon over XMPP
  513. kevin has left
  514. ralphm Zash: you are going to liason, right?
  515. Zash Yes, let me control port forwarding in my router with XMPP please!
  516. simon port forwarding is so ipv4 :)
  517. fsteinel has joined
  518. intosi Simon: open ports in your IPv6 firewall. Same stuff, different proto.
  519. Zash My router has Port Forwarding → Basic IPv6 → bunch of forwarding stuff
  520. simon my router has openwrt. Job done.
  521. ralphm simon: how is that relevant?
  522. ralphm simon: the idea is that there is a standard protocol for modifying firewall settings
  523. ralphm While UPnP might be horrible in some respects, at least there's something
  524. simon Ralphm: I totally get that.
  525. ralphm Zash: I was being serious about the liason thing
  526. Zash ralphm: There's a Port Control Protocol being developed, with less SOAP iirc
  527. intosi PCP, really?
  528. Zash ralphm: Huh, to who where?
  529. ralphm Zash: http://mail.jabber.org/pipermail/members/2013-December/007496.html
  530. Zash Did that involve NDAs?
  531. Zash intosi: https://datatracker.ietf.org/wg/pcp/
  532. Zash Oh, there's an {rfc 6887} already
  533. Bunneh Zash: Port Control Protocol (PCP). D. Wing, Ed., S. Cheshire, M. Boucadair, R. Penno, P. Selkirk. April 2013. (Status: PROPOSED STANDARD) http://tools.ietf.org/html/rfc6887
  534. intosi I was chuckling about the acronym.
  535. intosi Naming protocols after drugs and all.
  536. stpeter has left
  537. emcho has joined
  538. emcho has left
  539. Steffen Larsen has joined
  540. simon has left
  541. ralphm Zash: there's still some discussion on the extend of NDAs here
  542. tato has joined
  543. tato has left
  544. dwd has left
  545. dwd has joined
  546. bear has joined
  547. fsteinel has left
  548. Jef has left
  549. Simon has joined
  550. Jef has joined
  551. Simon has left
  552. dwd has left
  553. Jef has left
  554. bear has left
  555. Simon has joined
  556. Alex has left
  557. emcho has joined
  558. Steffen Larsen has left
  559. SouL has left
  560. bear has joined
  561. Steffen Larsen has joined
  562. Steffen Larsen has left
  563. dwd has joined
  564. Ash has left
  565. Ash has joined
  566. Ash has left
  567. Ash has joined
  568. Simon has joined
  569. emcho has left
  570. emcho has joined
  571. emcho has left
  572. emcho has joined
  573. Jef has joined
  574. Steffen Larsen has joined
  575. winfried has left
  576. Simon has left
  577. Ash has left
  578. Steffen Larsen has left
  579. bear has left
  580. tato has joined
  581. Ash has joined
  582. emcho has left
  583. emcho has joined
  584. emcho has left
  585. emcho has joined
  586. emcho has left
  587. emcho has joined
  588. Ash has left
  589. tato has left
  590. emcho has left
  591. tato has joined
  592. emcho has joined
  593. tato has left
  594. emcho has left
  595. emcho has joined
  596. emcho has left
  597. emcho has joined
  598. dwd has left
  599. emcho has left
  600. emcho has joined
  601. Jef has left
  602. emcho has left
  603. emcho has joined
  604. Alex has left