- dwd has left
- tato has left
- waqas has left
- Lance has joined
- bear has left
- waqas has joined
- emcho has joined
- emcho has left
- emcho has joined
- waqas has left
- waqas has joined
- bear has joined
- emcho has left
- emcho has joined
- waqas has left
- waqas has joined
- emcho has left
- emcho has joined
- emcho has left
- emcho has joined
- emcho has left
- emcho has joined
- emcho has left
- emcho has joined
- Jef has left
- emcho has left
- emcho has joined
- Lance has joined
- emcho has left
- emcho has joined
- bear has left
- emcho has left
- emcho has joined
- emcho has left
- emcho has joined
- emcho has left
- emcho has joined
- Lance has left
- emcho has left
- emcho has joined
- emcho has left
- emcho has joined
- emcho has left
- emcho has joined
- emcho has left
- emcho has joined
- waqas has left
- Steffen Larsen has joined
- Steffen Larsen has left
- Steffen Larsen has joined
- SouL has joined
- Steffen Larsen has left
- simon has joined
- emcho has left
- emcho has joined
- Steffen Larsen has joined
- dwd has joined
- emcho has left
- emcho has joined
- Steffen Larsen has joined
- Alex has joined
- Lloyd has joined
- Ash has joined
- dwd has left
-
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?
- SouL has left
-
Kev
If they're attending the summit I don't see why not.
-
Kev
If they're not, it seems more dodgy.
-
Steffen Larsen
he is not XSF.. and cant make it to the summit. He'll be there for FOSDEM
-
Steffen Larsen
Kev: thats alright
-
Steffen Larsen
Kev: No problem
-
Kev
I didn't give an answer.
-
Steffen Larsen
Ohh I thought you said it was dodgy
-
Kev
I'd see what Dave/Ralph say :)
-
Steffen Larsen
what that ever means
-
Kev
Dodgy/uncertain.
-
Steffen Larsen
;-)
-
Steffen Larsen
Ok
-
Steffen Larsen
just wanted to hear your oppion
-
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.
-
Steffen Larsen
Kev: so its ok to give him them link?
-
Kev
See what Dave/Ralph think.
-
Kev
I have no authority here :)
-
Steffen Larsen
Kev: Thanks!
- FloRida has joined
- FloRida has left
- FloRida has joined
- FloRida has left
- FloRida has joined
- dwd has joined
- FloRida has left
-
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.
-
Steffen Larsen
dwd: ok thats all fair.
-
dwd
http://www.keepcalm-o-matic.co.uk/p/keep-calm-and-encrypt-your-im/ anyone?
-
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
-
Steffen Larsen
dwd: Dave, how do we/I know when all people have booked?
-
dwd
Steffen Larsen, We don't. :-) Florian can watch the numbers though.
-
Steffen Larsen
dwd: ohhh..
-
dwd
Steffen Larsen, Using the entire block is actually a good thing; gives us more bargaining power next year.
-
Steffen Larsen
dwd: true true
-
dwd
Steffen Larsen, And of course it doesn't cost the XSF anything.
-
Steffen Larsen
dwd: even better
-
Steffen Larsen
dwd: BTW what did we agree about the dinner? was it saturday or?
-
dwd
Saturday, usual place and rules.
-
ralphm
Steffen Larsen: you mean you don't read the logs here?
-
dwd
So XSF Members and XSF Dinner sponsors only.
-
Steffen Larsen
cool
- emcho has left
- emcho has joined
-
Steffen Larsen
ralphm: sorry no
-
Steffen Larsen
dwd: yes i know
-
simon
.
-
simon
oops
- emcho has left
- emcho has joined
-
intosi
dwd: keep calm and order those shirts ;)
- SouL has joined
-
ralphm
keep calm and federate?
-
ralphm
hmm
-
dwd
ralphm, Yeah, it's not quite right, I agree.
- emcho has left
-
ralphm
http://www.keepcalm-o-matic.co.uk/p/keep-calm-and-federate--1/
-
ralphm
(I'm spending too much time in inkscape these days, it seems)
- SouL has left
- SouL has joined
-
dwd
Keep Calm and Use XMPP might work better with the lightbulb. (Or Use Jabber, mind)
-
dwd
Or KEEP CALM and JABBER SECURELY?
-
Kev
Just to check, we don't feel that Keep Calm And... has been overdone as a meme, do we?
-
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)
-
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.
-
dwd
"Trust your provider. Host IM yourself." or something?
-
Kev
I'm thinking along those lines.
-
Kev
Or "Keep Jabbering with those you trust" or ... something.
-
dwd
Kev, I think, BTW, that the meme has been so overdone it's almost meta.
-
Steffen Larsen
"Talk about federated security"..
-
intosi
In TLS we trust
-
Steffen Larsen
ha ha
-
ralphm
dwd: I do think that ... and encrypt your IM works for FOSDEM
-
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."
-
Kev
Haha
-
Kev
"We trust in the Federation"
-
Kev
I've made myself giggle :)
-
ralphm
but people might think that we mean e2e
-
intosi
dwd: classic Woody
-
Kev
Why does no-one like my Star Trek joke? I don't believe for a moment that you're not sufficiently nerdy :p
-
dwd
Kev, Other than I did "Federation: Not just for Star Trek" a year or two back?
-
ralphm
http://www.juxtapost.com/site/permlink/b15477f0-f5df-11e1-8de6-fba9fc1c5f14/post/bye_bye_robot_poster_the_federation_needs_you/
-
Kev
dwd: I don't remember that at all.
-
ralphm
I do
-
dwd
My wife is suggesting singing "I'm XMPPY, I'm XMPPY, I know I am - I'm sure I am - I'm XMPPY!"
-
ralphm
I'd be happy to reserve a slot for her at the Lounge.
-
ralphm
Live entertainment is something we didn't do much about, still
-
dwd
(She also suggests a school choir singing it. Obviously well in-tune with current tech thinking)
-
Steffen Larsen
wow that could be cool
-
ralphm
Perfect. Let me know which day/time.
- FloRida has joined
- FloRida has left
- FloRida has joined
- Steffen Larsen has left
- FloRida has left
- Steffen Larsen has joined
- Steffen Larsen has left
- simon has left
- simon has joined
- Jef has joined
- simon has left
- simon has joined
-
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.
-
MattJ
*nod*
-
MattJ
That has crossed my mind a few times, but actually I haven't seen anyone react that way yet
- winfried has joined
-
Ash
I think it's just something to be sensitive to
-
MattJ
After all, the web is far less encrypted than XMPP is
-
Ash
Exactly
-
intosi
As is email.
-
Ash
We just need to make sure the message is positive
-
simon
and in the background get our house in order.
-
dwd
Ash, I think we need to ensure we're being honest, open, and seeking improvement.
-
winfried
And the message is: "we are raising the bar even further and making sure it works" ;-)
-
simon
basically it comes down to good configuration (not lazy about certs / DNS etc) rather than something inherently wrong with XMPP's core design.
-
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.
-
simon
and keep pointing people to xmpp.net to test their sit.
-
simon
site
-
Ash
simon and winfried: definitely :)
-
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.
- dwd makes mental note to ensure the XSF's interop work a couple of years back gets noted in PSA's STRINT draft.
- emcho has joined
-
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'.
-
winfried
@Ash: it more like: "We are phasing out all but the most secure configurations" ;-)
-
Ash
even better!
-
fippo
winfried: well, we're not able to enforce authentication... so i don't think saying this is a good idea
-
simon
Geez - winifried is an excellent marketer. I'm nominating him to write xmpp.org content.
-
ralphm
simon: who are you?
-
simon
ralphm - I believe we've met at the odd XMPP event before.
-
ralphm
How can I be sure it's you?
-
intosi
Because Simon says… he's Simon.
-
intosi
That's how you play the game.
-
simon
until xmpp.org does cert verification or DANE, you can't.
-
dwd
simon, That won't help.
-
ralphm
simon: using anonymous.jabbix.com is the other extreme, though
-
simon
short of using corkscrew and some socks5 tunneling, I'm behind a crappy corp fw.
-
dwd
simon, That's what 3G is for. :-)
- kevin has joined
-
simon
what's the preferred XMPP client on android these days?
-
dwd
xabber doesn't work on newish Prosody, but jTalk might be OK.
-
ralphm
I want to say Xabber, but I can't use it
-
MattJ
Yaxim, but it doesn't do MUC yet
-
MattJ
dwd, it doesn't? Why?
-
dwd
MattJ, Because it breaks.
-
ralphm
(because it has some issues and development seems stalled or at least invisible)
-
MattJ
Yaxim is actively developed, supports XEP-0198 and Carbons
-
ralphm
https://github.com/redsolution/xabber-android/issues/264
-
MattJ
Completely open-source, and MUC is coming soon
-
MattJ
ralphm, nice
-
MattJ
it doesn't work on "newish Prosody"? I don't think we've ever had a release that would accept unescaped ampersands...
-
ralphm
MattJ: I don't think this particular bug is something related to Prosody at all
-
ralphm
MattJ: I did a c2s tcpdump for it, and decoded it with my server's key
-
MattJ
Fancy
-
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
-
ralphm
I suppose in the future you can't do that anymore, right?
-
ralphm
In any case, I would not go as far as calling XMPP secure, as it has many facets
-
winfried
:-) temporally disable FS
-
ralphm
winfried: I assume in the future, clients will require that?
-
winfried
point taken
-
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.
-
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.
-
ralphm
so anyway, besides heckling simon a bit, I agree with Ash' earlier point
-
simon
buddycloud.org /com already reject servers with invalid certs.
-
ralphm
simon: and without encryption, too?
-
simon
:) no - all s2s is encrypted.
-
ralphm
so you can't use your imaginator.com address
-
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.
-
ralphm
simon: yeah, I knew that the domain was with Google
-
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?
-
Ash
Buddycloud is magic!
-
ralphm
magic is cool, but I hope I misunderstood
-
fippo
there is a difference between encryption and authenticated encryption in terms a what attacks it protects you against
-
dwd
To be fair, BTNS mitigates a set of attacks that are a proper subset of those mitigated by authenticated encryption.
-
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.
-
ralphm
It still seems a bad idea to have two different servers at the same address
-
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
-
ralphm
If I misunderstood, please elaborate, though.
-
dwd
It suggests there's no commonality between a buddycloud server and an XMPP server, at least.
-
Lloyd
Its a special case for people who can't install a buddycloud component on their xmpp setup
-
Lloyd
so we run another xmpp server with the buddycloud component connected and use that
- Steffen Larsen has joined
-
ralphm
Lloyd: While I admire that stand point, it seems to me that this solution breaks the network.
-
simon
how does it break the network?
-
ralphm
By connecting to other servers based on something outside of the XMPP realm itself
-
dwd
simon, You're offering XMPP based services using a protocol that's no longer interoperable with XMPP?
-
simon
Using XMPP to exchange data between components is breaking network? I must have misread a XEP somewhere.
- stpeter has joined
-
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?
-
Lloyd
The server isn't modified at all. I think maybe something has been lost in the text description.
-
MattJ
What does the SRV lookup?
-
MattJ
(for the buddycloud discovery)
-
Lloyd
the buddycloud component. It still uses DISCO however.
-
Lloyd
Yes exactly
-
ralphm
So when is the SRV thing happening and why?
-
intosi
And what will it actually try to resolve?
-
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.
-
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.
-
ralphm
As I said, I want to be wrong about this and would be happy if buddycloud is pure XMPP
-
Lloyd
channels.imaginator.com is still running as a component on an xmpp server.
-
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?
-
ralphm
So it is really a fallback on channels.domain
-
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).
-
Lloyd
ralphm yes, disco+ so to speak (probably a *really* bad term)
-
Kev
simon: There's nothing that suggests that you should be using one server for everything.
-
Lloyd
kev it'll try and connect on domain anyway, if no advertised service will see if there's a DNS hint.
-
ralphm
simon: you may disagree and actually implement things in the background, but just doing something else entirely protocol-wise doesn't seem proper
-
Lloyd
if there's no dns hint, well other service doesn't run buddycloud :)
-
simon
Kev: my understanding too.
-
Kev
blah.doomsong.co.uk could be on the moon, and have no link to doomsong.co.uk other than S2S.
-
ralphm
I understand that you have to work around servers (like Google's) that you can insert disco records on
-
simon
Ralphm: not sure I really understand your concern.
-
Kev
simon: Because you're making something simple sound like you're re-inventing the wheel.
-
ralphm
simon: well, the description of what was happening initially sounded really horrible
-
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.
-
ralphm
simon: now I understand better I'm milder in my judgement
-
Kev
Misleading is the enemy of good, and all that.
-
simon
Don't think I claimed that this was rocket science. Just a nice way to host instances outside of their XMPP domain.
- Steffen Larsen has left
- Steffen Larsen has joined
- fsteinel has joined
-
Lloyd
*ahem* "maybe something has been lost in the text description" …. or gained as the case may be :)
-
ralphm
simon: arguably, nothing in XMPP is rocket science. But I dread having incompatible systems referred to as XMPP
-
ralphm
like, say, whatsapp
-
MattJ
ralphm, I think by your definition, if you haven't been following Buddycloud, it took that route long ago
-
MattJ
It uses XMPP purely as a transport mechanism nowadays
-
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
-
ralphm
MattJ: turns out it has nothing to do with SRV in principle
- Steffen Larsen has left
-
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.
-
ralphm
isn't that what I said?
-
ralphm
the initial explanation was worse
-
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?
-
intosi
You mean on the A or AAAA record listed for channel.domain?
-
ralphm
yes
-
Lloyd
ralphm: yes, standard disco is the preference, DNS is the fallback
-
ralphm
see this is the confusing bit
-
intosi
So, normal 6120 §3.2 behaviour?
-
ralphm
if you say 'channels.' is the fallback, *then* it is clear
-
ralphm
You don't need to talk about DNS in the case, even though it is involved
-
simon
it falls back to looking for a SRV record - if that isn't there then it gives up.
-
ralphm
so that's unlike normal lookup for s2s
- Zash has joined
-
simon
who said it was s2s.
-
intosi
Well, that's what you were implying earlier, as I understood it.
-
Kev
You did, implicitly, when you said you were doing standard XMPP.
-
simon
component to component if you want to name it.
-
Kev
There is no XMPP component to component protocol.
-
MattJ
component1->server1->server2->component2
-
Kev
So, S2S, then.
-
simon
thanks MattJ.
-
simon
So if there's a XEP that says how components should be delegated, I'd love to see it.
-
ralphm
XEP-0114 is a server side protocol, totally irrelevant for inter server communication in any sense
-
simon
but since there isn't I don't think applying the entire s2s stack to discovery makes sense.
- fsteinel has left
-
ralphm
the entire s2s stack isn't much is it
-
ralphm
it is setting up streams between servers
-
ralphm
Note that I am trying to be very exact here
-
Kev
simon: A component is, to the outside world, just another server.
-
ralphm
while Google is one big distributed beast posing as many servers
-
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.
-
ralphm
s2s-wise you can't tell the diff
-
Kev
simon: It doesn't talk to a component. It talks to a server.
-
ralphm
simon: I don't care how buddycloud's organised internally
-
ralphm
I only care about the edges, in this case s2s
-
ralphm
Similarly, protocol-wise, there's nothing to prevent having MUC rooms and user accounts at the same domain
-
ralphm
(say, ralphm@jabber.org and jdev@jabber.org)
-
MattJ
Prosody allows it :)
-
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?
-
ralphm
apparently 'try channels.bc-hosting-cloud.org' instead
-
ralphm
without any additional changes
-
simon
really?
-
ralphm
I assume you know how it works
-
simon
that seems to do away with a lot of the correctness of using SRV to say this is the service that runs X.
-
ralphm
wat?
-
ralphm
once you are ready to try channels.domain, you try dns srv, if missing dns a and aaaa and [ort 5269
-
ralphm
like s2s always does?
- waqas has joined
-
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.
-
intosi
Sure.
-
simon
correction that the remote server is channels.ik.nu
-
intosi
Then try the hosts and ports for s2s as per 6120 §§ 3.2.1 – 3.2.2.
-
simon
why would it try channels.ik.nu and not other-service-name.ik.nu?
-
simon
remember if you user@domain.com on buddycloud not user@buddycloud-component.domain.com
-
simon
https://github.com/buddycloud/buddycloud-xep/blob/master/buddycloud.xml#L483
-
simon
(XEPign now)
-
intosi
simon: because you just defined it would, if no other service was disco'd on ik.nu
-
simon
fair enough. I just don't think it's a great idea to hardcode expected hostnames into code.
- kevin has left
-
simon
it's not like we expect to connect to XMPP.domain.com as a fallback for discovery.
-
intosi
simon, you misunderstood. You're defining a fallback for your BC disco.
-
intosi
As far as I understand, you defined this as channels.domain
-
simon
I explained that you don't know the component on the remote server that offers buddycloud services.
- emcho has left
- emcho has joined
-
simon
Does this help http://imgur.com/4y2BTvd ?
-
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?
-
simon
_buddycloud-server._tcp.imaginator.com. (code for the curious: https://github.com/buddycloud/buddycloud-server-java/pull/114)
-
ralphm
simon: now it is clear. Thanks.
-
simon
ralphm: :)
-
ralphm
simon: I'm not sure why it took this long to get to this :-(
-
intosi
You should've pointed to this commit immediately. Would've saved a lot of discussion.
-
ralphm
simon: I also think this was the feared answer
-
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
-
Zash
How does that work with IDNA?
-
intosi
A PTR would be better suited, a la DNS-SD
- fsteinel has joined
-
waqas
Without DNSSEC (and we'll be without DNSSEC for a while), isn't relying on DNS for this insecure?
- fsteinel has left
- fsteinel has joined
-
ralphm
intosi: agreed. DNS-SD is great for this
-
ralphm
waqas: I wanted to leave DNSSEC out of this particular discussion
-
ralphm
it is rather orthogonal
-
MattJ
(but it is insecure ;) )
-
ralphm
MattJ: what ever, man
-
waqas
Well, there is no trust here if there's a third-party able to send DNS responses to the client
-
intosi
MattJ: live a litte. On the edge, man!
-
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
-
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.
-
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?
-
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.
-
ralphm
waqas: in this implementation, yes. If he used PTR records, it would be better
-
ralphm
simon: no, because the discovery doesn't do fallback on A/AAAA records
-
simon
how is fallback magically secure?
-
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
-
ralphm
(the key here is *domain* v.s. server)
-
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
-
ralphm
waqas: yes, that can't happen for something like Google Talk
-
Zash
waqas: Because in this scenario that server does not support that
-
ralphm
waqas: that's why it is there to begin with
-
intosi
For sane servers, this isn't needed at all.
-
ralphm
POSH is an alternative, sure
-
waqas
So.. is there a server which gets to be /the/ gtalk buddycloud server?
-
waqas
I don't see how this solves the gtalk issue, gtalk isn't going to change their DNS
-
ralphm
waqas: if you host your domain at google
-
ralphm
waqas: you control your own DNS, but not the server implementation
-
ralphm
waqas: so you can't rely on disco
-
waqas
Ah, I see, in which case you can do POSH too, no?
-
ralphm
waqas: yes
-
waqas
And POSH in that case would be secure, as opposed to DNS? :)
-
waqas
Anyway, I'm dragging this on, ignore me
- emcho has left
-
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).
-
waqas
POSH will remain much easier for quite a few years I think
-
ralphm
simon: that still makes your solution suboptimal
-
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
- fsteinel has left
-
ralphm
(-o)
-
simon
If your DNS is poisoned, how does PTR help over SRV?
-
waqas
Indeed, I don't see how PTR is any more secure
-
ralphm
I am not talking about DNS poisoning. It is orthogonal to SRV being a bad choice for pointing buddycloud to another domain
-
ralphm
which was the discussion originally
-
intosi
waqas: it's not about being more secure, it's about using the appropriate record the the job.
-
waqas
Ah, k
-
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.
-
waqas
ralphm: From a security perspective, or without considering security?
-
ralphm
from a security perspective
-
waqas
Certs being proper does nothing to establish that serverA trusts serverB with this service
-
simon
Side note: by using PTR, the local buddycloud component must go through a bunch more roundtrips for disco-ing the right component.
-
intosi
simon: no. The component will just use the name returned and use that as the remote component domain.
-
dwd
I'm confused still. So the SRV is looked up, and returns IN SRV 5 0 5269 buddycloud.imaginator.com, right?
-
intosi
The XMPP server the component is connected to will route it.
-
dwd
What does the local component route to here?
-
ralphm
dwd: no the actual machine
-
ralphm
dwd: so, say, 'spock.imaginator.com'
-
ralphm
I'm not sure which domain is used within XMPP at that point, by the way
-
dwd
ralphm, I'm using the example on the pull request.
-
dwd
ralphm, Exactly. Does the component use "buddycloud.imaginator.com", and therefore that *too* has SRV records, this time for xmpp-server?
-
intosi
If you want to use it as an alternative to disco, that's the only way it should work.
-
dwd
OK, but what do the port numbers mean? ANd what's the handling for multiple SRV?
-
intosi
dwd: that's why I suggested SRV was the wrong record, and PTR should be used instead.
-
Zash
There's also a URI records somewhere
-
dwd
Zash, NAPTR? Yay!
-
dwd
Zash, Actually the URI variant is U-NAPTR, pronounced "Unapointer", a bit like the Unabomber, and almost as scary.
-
intosi
:)
- Lloyd has left
-
intosi
And again introduces priority and weight.
-
intosi
Although it's probably more appropriate than using SRV.
-
dwd
intosi, Anything other than CNAME will have some case of multiple records.
-
dwd
intosi, CNAME, mind, seems like a reasonable option.
-
Zash
dwd: I was thinking of https://tools.ietf.org/html/draft-faltstrom-uri-06
-
intosi
Could be.
-
intosi
CNAME or PTR are both more appropriate for this than SRV.
-
ralphm
I also assume that 'buddycloud' is not a registered service at IANA. I don't recall if PTR has that restriction.
-
ralphm
but SRV does
-
intosi
Although resolvers might try to get the A or AAAA of a CNAME automatically.
- FloRida has joined
- FloRida has left
-
intosi
^resolvers^resolver libraries
- kevin has joined
-
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)
-
ralphm
ah, cool
-
ralphm
simon: but I would definitely switch to something based on PTR
-
ralphm
or at least not using SRV like it is now
-
simon
(buddycloud-api is used by mobile clients needing to find the HTTP endpoint for API calls)
-
ralphm
does *that* use PTR?
-
dwd
TXT by the looks of things.
-
intosi
I'd say a U-NAPTR would be more appropriate ;)
-
simon
ralphm: TXT as defined in the DNS-SD RFC https://groups.google.com/d/msg/buddycloud-dev/ww0yjdwRuNY/Qf7930KxG7MJ
-
dwd
Ah, the iPod RFC.
-
ralphm
dwd: hah!
-
simon
The format actually makes a lot of sense for describing how to connect to remote services.
-
dwd
You've read it too, huh?
-
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.
-
simon
They had working implementations before writing the spec. Shocker!
-
dwd
Yes... So?
-
simon
dwd: looks like it is going through ietf https://tools.ietf.org/html/rfc6763
-
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.
-
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.
-
simon
IMHO it's a good spec. Don't know why we're talking about Apple here.
-
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.
-
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.
-
dwd
simon, Any changes were rejected because they'd already deployed, of course.
-
dwd
simon, I agree that DNS-SD is a good spec. So was Zeroconf, but Apple effectively destroyed that one.
- Lance has joined
-
ralphm
dwd: hm? I thought DNS-SD built on Zeroconf, I don't know the history much
-
dwd
No, parallel development. Apple was involved in both IIRC.
-
dwd
They're *very* similar.
-
ralphm
oh
-
simon
dwd: you mean the old link local name resolution drafts?
-
ralphm
I can't make out the difference from the wikipedia page
-
simon
"local link multicast name resolution"
-
dwd
The differences are small but incompatible, according to Appendix G.
-
ralphm
oh, but that's Microsoft's stuff, right?
-
Zash
Yeah, isn't there a Microsoft one too
-
ralphm
LLMNR, what simon mentioned
-
Zash
Which one is mDNSSD then?
-
ralphm
mDNS an DNS-SD are two things
-
ralphm
mDNS is for doing DNS on lans
-
ralphm
with .local
-
Zash
and multicast
-
Zash
right
-
ralphm
hence the m
-
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
-
ralphm
I so wish that more things supported mDNS and DNS-SD
-
ralphm
So happy that my Ubuntu laptop can find my printer at officejet.local
-
ralphm
Unfortunately, support in Android is non-existant
-
ralphm
I SSH between my boxes at home with .local addresses exclusively
-
simon
Android music strategy is currently "send everything over bluetooth" which seems rather daft.
-
ralphm
wait huh?
-
simon
unless I missed a new app that lets me stream to my raspberryPi via wifi.
-
ralphm
I use ChromeCast, but yes, that space is still a bit of a mess
-
simon
(ralphm: one thing that Zeroconf solved nicely on the Apple side was announcing music recivers via Bonjour/Zeroconf/mDNS)
-
ralphm
although UPnP also builds on stuff like zeroconf/mDNS/DNS-SD
-
Zash
UPnP, the SOAP-over-HTTP-over-UDP thing?
-
ralphm
simon: indeed, my Rhythmbox announces itself as Ralphonics and Apple devices can play from it
-
ralphm
visa versa is horrible because of Digital Restrictions
-
ralphm
Zash: soon over XMPP
- kevin has left
-
ralphm
Zash: you are going to liason, right?
-
Zash
Yes, let me control port forwarding in my router with XMPP please!
-
simon
port forwarding is so ipv4 :)
- fsteinel has joined
-
intosi
Simon: open ports in your IPv6 firewall. Same stuff, different proto.
-
Zash
My router has Port Forwarding → Basic IPv6 → bunch of forwarding stuff
-
simon
my router has openwrt. Job done.
-
ralphm
simon: how is that relevant?
-
ralphm
simon: the idea is that there is a standard protocol for modifying firewall settings
-
ralphm
While UPnP might be horrible in some respects, at least there's something
-
simon
Ralphm: I totally get that.
-
ralphm
Zash: I was being serious about the liason thing
-
Zash
ralphm: There's a Port Control Protocol being developed, with less SOAP iirc
-
intosi
PCP, really?
-
Zash
ralphm: Huh, to who where?
-
ralphm
Zash: http://mail.jabber.org/pipermail/members/2013-December/007496.html
-
Zash
Did that involve NDAs?
-
Zash
intosi: https://datatracker.ietf.org/wg/pcp/
-
Zash
Oh, there's an {rfc 6887} already
-
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
-
intosi
I was chuckling about the acronym.
-
intosi
Naming protocols after drugs and all.
- stpeter has left
- emcho has joined
- emcho has left
- Steffen Larsen has joined
- simon has left
-
ralphm
Zash: there's still some discussion on the extend of NDAs here
- tato has joined
- tato has left
- dwd has left
- dwd has joined
- bear has joined
- fsteinel has left
- Jef has left
- Simon has joined
- Jef has joined
- Simon has left
- dwd has left
- Jef has left
- bear has left
- Simon has joined
- Alex has left
- emcho has joined
- Steffen Larsen has left
- SouL has left
- bear has joined
- Steffen Larsen has joined
- Steffen Larsen has left
- dwd has joined
- Ash has left
- Ash has joined
- Ash has left
- Ash has joined
- Simon has joined
- emcho has left
- emcho has joined
- emcho has left
- emcho has joined
- Jef has joined
- Steffen Larsen has joined
- winfried has left
- Simon has left
- Ash has left
- Steffen Larsen has left
- bear has left
- tato has joined
- Ash has joined
- emcho has left
- emcho has joined
- emcho has left
- emcho has joined
- emcho has left
- emcho has joined
- Ash has left
- tato has left
- emcho has left
- tato has joined
- emcho has joined
- tato has left
- emcho has left
- emcho has joined
- emcho has left
- emcho has joined
- dwd has left
- emcho has left
- emcho has joined
- Jef has left
- emcho has left
- emcho has joined
- Alex has left
- dwd has left
- tato has left
- waqas has left
- Lance has joined
- bear has left
- waqas has joined
- emcho has joined
- emcho has left
- emcho has joined
- waqas has left
- waqas has joined
- bear has joined
- emcho has left
- emcho has joined
- waqas has left
- waqas has joined
- emcho has left
- emcho has joined
- emcho has left
- emcho has joined
- emcho has left
- emcho has joined
- emcho has left
- emcho has joined
- Jef has left
- emcho has left
- emcho has joined
- Lance has joined
- emcho has left
- emcho has joined
- bear has left
- emcho has left
- emcho has joined
- emcho has left
- emcho has joined
- emcho has left
- emcho has joined
- Lance has left
- emcho has left
- emcho has joined
- emcho has left
- emcho has joined
- emcho has left
- emcho has joined
- emcho has left
- emcho has joined
- waqas has left
- Steffen Larsen has joined
- Steffen Larsen has left
- Steffen Larsen has joined
- SouL has joined
- Steffen Larsen has left
- simon has joined
- emcho has left
- emcho has joined
- Steffen Larsen has joined
- dwd has joined
- emcho has left
- emcho has joined
- Steffen Larsen has joined
- Alex has joined
- Lloyd has joined
- Ash has joined
- dwd has left
- SouL has left
- FloRida has joined
- FloRida has left
- FloRida has joined
- FloRida has left
- FloRida has joined
- dwd has joined
- FloRida has left
- emcho has left
- emcho has joined
- emcho has left
- emcho has joined
- SouL has joined
- emcho has left
- SouL has left
- SouL has joined
- FloRida has joined
- FloRida has left
- FloRida has joined
- Steffen Larsen has left
- FloRida has left
- Steffen Larsen has joined
- Steffen Larsen has left
- simon has left
- simon has joined
- Jef has joined
- simon has left
- simon has joined
- winfried has joined
- emcho has joined
- kevin has joined
- Steffen Larsen has joined
- stpeter has joined
- Steffen Larsen has left
- Steffen Larsen has joined
- fsteinel has joined
- Steffen Larsen has left
- Zash has joined
- fsteinel has left
- waqas has joined
- kevin has left
- emcho has left
- emcho has joined
- fsteinel has joined
- fsteinel has left
- fsteinel has joined
- emcho has left
- fsteinel has left
- Lloyd has left
- FloRida has joined
- FloRida has left
- kevin has joined
- Lance has joined
- kevin has left
- fsteinel has joined
- stpeter has left
- emcho has joined
- emcho has left
- Steffen Larsen has joined
- simon has left
- tato has joined
- tato has left
- dwd has left
- dwd has joined
- bear has joined
- fsteinel has left
- Jef has left
- Simon has joined
- Jef has joined
- Simon has left
- dwd has left
- Jef has left
- bear has left
- Simon has joined
- Alex has left
- emcho has joined
- Steffen Larsen has left
- SouL has left
- bear has joined
- Steffen Larsen has joined
- Steffen Larsen has left
- dwd has joined
- Ash has left
- Ash has joined
- Ash has left
- Ash has joined
- Simon has joined
- emcho has left
- emcho has joined
- emcho has left
- emcho has joined
- Jef has joined
- Steffen Larsen has joined
- winfried has left
- Simon has left
- Ash has left
- Steffen Larsen has left
- bear has left
- tato has joined
- Ash has joined
- emcho has left
- emcho has joined
- emcho has left
- emcho has joined
- emcho has left
- emcho has joined
- Ash has left
- tato has left
- emcho has left
- tato has joined
- emcho has joined
- tato has left
- emcho has left
- emcho has joined
- emcho has left
- emcho has joined
- dwd has left
- emcho has left
- emcho has joined
- Jef has left
- emcho has left
- emcho has joined
- Alex has left