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)

  127. dwd

    Or KEEP CALM and JABBER SECURELY?

  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