XSF Discussion - 2017-09-25

Is it possible to test XEP-0368 Direct TLS without actually creating the DNS records? You can't put SRV into hosts files :(

Ge0rG, test the implementation at the client or at the server?

jonasw: test a server deployment

Ge0rG: dnsmasq running locally.

most clients allow to specify a port

and a host to connect to explicitly

so you’d use that

Yeah, I once enabled it in Gajim with a dozen clicks or so.

guys, what string should be put in SNI in the case of IDN domain? original or pynnycoded?

zinid, interesting question, that I’d like to know too :-)

ah, found in RFC6066

"HostName" contains the fully qualified DNS hostname of the server, as understood by the client. The hostname is represented as a byte string using ASCII encoding without a trailing dot. This allows the support of internationalized domain names through the use of A-labels defined in [RFC5890].

so should be punnycoded

mhm

I wonder if I should move the yax.im A records to point to the XMPP server instead of the web server, so that clients that fail SRV will still properly connect.

It looks like 15% of client connections ignore SRV for yax.im

Hi, I'd like to know the state of this PR ? https://github.com/xsf/xeps/pull/500

edhelas, I think some council votes are pending, I haven’t processed last council meetings minutes yet, sorry

edhelas, most efficient will be if you ping me on the PR, I’ll take care of it when I get home

okay

I'm also planning to do other PR on 0060, maybe today

jonasw what is your github account nickname ?

edhelas, @horazont

danke

de rien

I'm also planning to do another PR on 0060, but I'd like to get some feedbacks here before

I'd like to expose the access_model of the nodes in their metadata

I'm wondering if this could brings issues

basically adding pubsub#access_model there https://xmpp.org/extensions/xep-0060.html#entity-metadata

> It looks like 15% of client connections ignore SRV for yax.im Would be interesting to know what clients those are and whether or not they are using Tor

conversations.ims numbers are equally high. Maybe even closer to 20%

I'll do some version logging for the next days.

Ge0rG, how are you going to track that?

also, I’ve seen clients fall back to A/AAAA if they try to connect before DNS is up

jonasw: modified mod_query_client_ver in prosody. Non-SRV connections to yax.im all come through a NAT on the web server

the SRV lookup fails (and they cannot necessarily distinguish the reason) and go on with A/AAAA, which may then pass :/

I've had very often "Connection refused" errors from my own yaxim instance for a week or so, and then I realized the NAT rule got reset.

I think that the A/AAAA fallback may be doing more harm than good

I’ve had very confusing certificate errors for weeks until I realized that A/AAAA pointed to a test instacne which wasn’t supposed to be live where the certificates had expired. I don’t even want to know what happened *before* the certificates expired ...

jonasw: it's clearly a bug, the question is just _where_.

the root cause is probably that applications cannot (do not?) distinguish between "network errors" and "records don’t exist"

Yeah.

with validating resolvers, you’ll also always rather see a generic validation error in favour of a NXDOMAIN if the backedn experienced network errors

so that isn’t going to go away

well, okay, that actually improves things.

if the API exposes the difference

It looks like most Non-SRV connections are from yaxim, followed by Conversations. And then some Pidgin and Cackle.

However, the stats are skewed because I query on new connections, and those happen far more often on mobile

and your userbase is probably also skewed

towards yaxim

No way! I'm a neutral server operator!

that may be, but are you also a neutral app developer? ;-)

cackle is just a Conversations fork though

or theme

There also was one MAXS.

MAXS <3

MAXS <3

♥

daniel: did you change the DNS records for conference.siacs.eu around noon on Saturday? My prosody wasn't able to resolve the server in the morning, then came up with an old(?) IP aroung 11:15, and then failed to resolve again.

Ge0rG, we switched over on friday at ~23:45

i don't think i've touched the records since

daniel: I'm sure this was a weirdness in prosody's DNS code, but I wanted to be 100% sure with that.

daniel: and 78.47.217.197 was the old IP?

sounds about right

daniel: I'll quote you on https://prosody.im/issues/issue/1001 if that's ok.

i just created srv records. but that doesn't seem to help

or maybe it did and just takes some time to propagate https://status.conversations.im/reverse/conference.siacs.eu/

let's wait and see what happens

prosody has some strange bugs in handling CNAMEs.

creating the srv record did in fact fix it

daniel: ...worked around ;)

semantics

The XSF is 90% about semantics.

CNAMEs are really odd. They shouldn't work (but might) in combination with SRV records, for a start.

Yeah, but they don't even work without SRV.

Ge0rG, Arguably they shouldn't - RFC 6120 § 3.2.2 only says A or AAAA. That probably implies CNAME (and DNAME), though.

DNAME is entirely DNS-server-side anyways, isn’t it?

Ge0rG, You *can* - in principle - use CNAMEs for, say, _xmpp-server._tcp.example.org. Just not for whatever the hostname it looks up to is.

jonasw, There's a fallback to do that, but I think there's an EDNS0 flag for handling them client-side.

dwd: but the service name is a CNAME, and it doesn't resolve

Ge0rG, What do you mean by the service name?

dwd: conference.siacs.eu. 300 IN CNAME xmpp-hosting.conversations.im. xmpp-hosting.conversations.im. 300 IN A 91.250.85.114

So that only works is the process looking up decides it'll use gethostbyname/getaddrinfo, or else do DNS directly but follow CNAMEs.

Neither is spelt out in RFC 6120 § 3.2.2.

I'm not sure RFC6120 is the right place to define how DNS should work.

However, with the wording you referenced, I could blame daniel for not following the RFC, instead of blaming prosody for having a broken CNAME lookup mechanism.

given that we have SRV, I don’t see the reason for CNAMEs in any case.

(as mentioned earlier, I think the A/AAAA fallback does more harm than good)

jonasw: SRVs happen to be black magic from the future for many DNS providers.

what

So the Prosody people broke their CNAME caching in order to strictly follow RFC 6120?

lol

jonasw: with some DNS operators, you can't add SRV entries.

Holger, just for the record... no :)

Ge0rG, I understood, but I am horrified

so these providers don't follow RFC6120?

we need to notify them

zinid: oh, they do.

it's the others that don't.

jonasw: You might have the CNAME record for other services anyway. Apart from that you might want to maintain the SRV targets in a single record and have multiple CNAMEs pointing to that.

dwd: I agree with Ge0rG that 6120 sounds like the wrong place to specify such things. But if it's the right place, then missing CNAME support sounds like an obvious 6120 bug to me.

Holger, I don't think it is specifying how DNS works. I do think it ought not to be quite so precise in the lookups involved.

Just sounds wrong to me that each and every protocol that uses DNS names should specify "yes we also resolve CNAMEs like everyone else".

As opposed to just specifying the parts that are *specific* to this protocol.

I bet there’s some wording in the document defining CNAME that resolvers (including stub resolvers) MUST follow CNAMEs transparently or so

> ‎[14:07:11] ‎jonasw‎: (as mentioned earlier, I think the A/AAAA fallback does more harm than good) Given the amount of DNS implementations not supporting SRV RRs, I doubt that this is true

what Holger said

just let's use NAPTR to break things completely :)

Flow, is there a list of such popular services?

and IM services hosted there? they should apply some pressure.

jonasw: I'm not only talking about services, more about all things DNS

the issue with the fallback is that it forces services using SRV records to also have valid A/AAAA records or at least it constraints what you can do with the A/AAAA of the domain.

jonasw: It doesn't force them

but yes, for maximum connectivity you want to have your XMPP domain also resolve A/AAAA

Flow, no, if there are intermittent issues which makes the client believe that the SRV records don’t exist, they fall back to A/AAAA

and that’s an issue

it's an issue if there are no A/AAAA records

or if the records point to something which isn’t the XMPP service you wanted to connect to

but how would not having the A/AAAA fallback improve the situation

if there are no A/AAAA records, it is more or less obvious to clients that they should re-try later because it’s most likely network

(or a configuration error)

but if end up in the fallback (e.g. on a transparent stream-managmeent reconnect) and the fallback is not the XMPP service you’re looking for, a lot of funny stuff can happen, from certificate errors, over stream errors to authentication failed

all of which will probably nuke the clients state

that’s what I mean by "harm"

(I had that once with an unfortunately configured A/AAAA record which pointed to another XMPP service)

(took me weeks to figure out what the reason for those errors were)

jonasw: I see, but without the fallback you wouldn't even be able to connect as soon as SRV breaks for some reason

Flow: yes, and treating it as a network error would do the right thing (retry soon)

jonasw: Not if it's your resolver lib not being able to perform SRV lookups

or you home router resolver

but you can't distinguish a wrong A/AAAA you should never have seen from incorrect credentials or something

incorrect credentials should return a well defined error, no?

but, yes, the situation is not ideal

Flow: sure it does, but you can get such an error when connecting to the wrong xmpp service due to A/AAAA lookup

i see

When I send a MUC join and lose my connection, so that it will be closed by a 0198 timeout, prosody will send error responses to all queued stanzas, including individual MUC participants. Is that good / bad / ugly / all of the above?

Ge0rG, I think MUCs won’t route error messages back. sending back error presences is the right thing.

Except that some funny MUC implementation will also kick all my MSNs

or is that NMSs?

sure, but that are broken MUC implementations then

not sending unavailable presence would be desastrous

jonasw: it's okay to send presence-unavailable to my own nickname, but to all the participants?

oh!

or rather, presence-error.

to the participants doesn’t seem right to me

Ge0rG, I'm not sure I understand what the problem you're describing is.

it's right from the 0198 session destruction context, though.

What's the downside with just dropping all presence stanzas on 0198 timeout?

How does the error stanza help anyone?

If you send presence to someone, do you expect an error if they don't ever receive it?

Ge0rG, So you have an existing local session connected to a local MUC, in a 198-detached state, and then this times out?

MattJ: I don't.

MattJ: Because how would I handle that error?

Holger, Giant modal dialog box of course.

Hehe.

Holger, I'm surprised you had to ask.

dwd: I'll try again: 1. I send a join presence to a MUC 2. I disappear into the void 3. The MUC sends everything that's sent on join to my 0198 cache 4. my 0198 session gets destroyed, so my server sends an error response for each individual stanza in the cache, including all the participant presences.

Ge0rG, Ah, OK. And what's wrong with that?

dwd: the flood of presence errors to MUC participants.

Ge0rG, Ah, OK. And what's wrong with *that*?

dwd: that was the point of my question. Is it wrong or just ugly.

Being useless?

Holger, Useless is OK, or at least it's nothing bad, surely?

It's nothing bad.

I’m not sure

sending presences to other MUC participants is at least weird

Ge0rG, I think it's right. Although I don't think the MUC should be broadcasting presence errors - it should juts error you out fo the MUC and broadcast that.

because that’s normally how you join/change nicknames

dwd: I don't know what the MUC does with the flood, to be honest

Ge0rG, If it just absorbs it, that's fine. I think.

dwd: sounds reasonable to me.

Ge0rG, The problem is that to stop it, we'd need to track not just the stanzas, but the semantics of those stanzas.

And that's really the MUC entity's job, I think.

shouldn’t all MUC presences have an <x/> in them which makes it easy to find?

(At least, wherever possible)

Nah.

jonasw: and <x/> specific code in 0198 as well, now?

Ge0rG, *shrug*

My question was: My not just silently drop *all* presence stanzas on 0198 timeout?

Let's fix 0045 first.

No matter whether MUC-related or not?

Is there a single use case where the originator of the presence would handle the error message in any other way than ignoring it?

Holger, I don't think that's needed, or desirable. If an error would be generated immediately on session close, then it should be generated on 198-closure.

It would not be generated without 0198, no?

does one get presence-errors when sending a presence to an unavailable entity?

This is a 0198 (mis)feature.

No.

jonasw, Ah, that's a "sort of". You get a presence error if your sending the presence causes an error to be detected.

Speaking of 198, what are people setting the timeout to these days?

I have it set at 10 minutes. ✏

jonasw, Any statistics on hit/miss of resume attempts?

On my personal server I set it to 2h, because when on bad mobile my data connection might get interrupted for so long due to a phone call

dwd, I don’t think I have logs with enough detail, also my userbase is approximately 10.

Ge0rG: Is that a CDMA thing that your data gets cut off when you're on a call?

SamWhited: no, it's a 2G/LTE thing.

When I looked some years ago, my impression was that most resumptions happen within 5 minutes. Which seems to be a common default.

SamWhited: 3G can route voice and data at the same time, the others can't

I.e. increasing the timeout significantly won't increase the resumption rate significantly.

dwd: there might be false negatives due to client restarts (e.g. OOM conditions)

Ge0rG: I'm reasonably sure LTE can, no? Maybe my phone is using both or something to get around that restriction. I should look into this.

Ge0rG, That wouldn't give a resume attempt, no?

SamWhited: only if you have VoLTE

SamWhited: otherwise, your phone will fall back to 3G or 2G, whatever's there.

Oh! Right, forgot that was a thing.

Ge0rG, I mean, it would give a resource conflict and killing the original detached session.

dwd: right

(for now).

until people start using random resource IDs.

Or rather, I forgot CSFB was a thing. Ge0rG: You're in the U.S. no? Do some providers not support SVLTE or VoLTE?

SamWhited: I'm in Germany. VoLTE support is rather spotty here, and you need a manually selected "compatible" phone.

dwd: That's how Cisco Jabber did it initially.

Ge0rG: Good to know; thanks. I wrote about this stuff a bit in the mobile considerations XEP, but obviously don't actually know what I'm talking about

unbounded 0198 sessions guarantee awesome UX

Ge0rG, But quite high memory usage, I suspect.

(And when the client didn't resume for some reason and tried to open a new session with the same resource, the new session was rejected.)

dwd: memory consumption is something usually not seen by your users. An "online" buddy that doesn't react for days, and where all the messages vanish, does.

Holger: yeah, that's awesome!

Depends who your users are.

I wonder whether unbounded sessions are indeed possible with some tricks

If you make an appliance that someone else runs, your users notice high memory usage.

jonasw: possible - maybe. practical - nope.

like: instead of storing messages in some memroy buffer, refer to MAM. apply CSI rules to drop messages.

presence is trickier, IQs too

jonasw, The problem is what other users see.

dwd, is it? is presence even a relevant thing anyomre?

jonasw, Although we could do some magic there, even, by triggering unavailable presence but leaving the session open. MUC dies, of course, but MIX would stay live.

jonasw, Yeah, it's relevant. Conversations notwithstanding, there's lots of IM applications where presence is as vital as it always used to be.

dwd, while I have you here: a friendly reminder that there are still missing votes from you on the last council meeting :)

jonasw, Oh, yeah. Weird bug hit me, so I was in the room but not seeing anything. I need to track that one down.

dwd: maybe you weren't in the room at all then?

0045 has a nice set of desync issues.

Ge0rG, Oh, I was. Got the presence, too. Just not the messages. I've half a feeling I've cocked something up somewhere. I've literally no idea what build I've been running.

Brand new web client, first field I tried was an XSS and naturally I can't find a security contact.

SamWhited, excellent!

I give up. I should just go blackhat, it would be way easier.

SamWhited: But it's shiny!

Honestly, I've given up reviewing JS/HTML XMPP clients, and will fail to trust any unless I write one myself

I suppose that's not limited to XMPP clients...

For the sake of my sanity I should do the same.

And the shinier and fancier they are, typically the worse the lack of even slight thought put into security hardening

waqas, that’s my impression, too

and I haven’t even tried to pentest anything :)

On the plus side, 3 seconds (if that) from login to XSS might be a new record. I am not happy about this, record, but I guess it's nice to have a new personal record?

SamWhited: I admit, I haven't broken one in 3 seconds yet :)

SamWhited, is it free or open source software? post to oss-security ;-)

SamWhited, congrats, too

waqas: I literally logged in, pasted a stupid simple XSS into the first field I saw, and sure enough it worked.

how can you even have such things if you do XML

that sounds as if you could also paste raw XML into the XML stream

jonasw: Interpret it as HTML, obviously

jonasw: Probably. In this case that's not what was happening (it was a roster group name being decoded and inserted into the DOM as HTML)

SamWhited: I'd bet it's string concat. blah.innerHTML += "<div>" + text + "<div>";

SamWhited, sure, but ... but ... I can’t even. so they used innerHTML?!

the world is bad

SamWhited: but roster groups are only visible to yourself!1!

Ge0rG: Yah, that particular one might not be the worst attack vector since they'd have to have access to your client anyways I guess. Either way, it probably means there are others.

Yeah. That's probably true. Sad, but true.

isn’t there a way to share roster items? ;-)

jonasw: roster item exchange?