I'm planning to provide some improvements to SIMS xep. And I think this recent unique MUC occupant id xep would be useful here. Is it going to be published any soon?
jonas’
rion, I expect it to be accepted
jonas’
but that’s just me ;)
jonas’
still lacks two council votes because the respective members weren’t available for the meeting yesterday
jonas’
which means it’ll probably be dealt with next wednesday
igoosehas left
Zash
What kind of improvements?
Ge0rG
The biggest issue I have with the occupant-id thing is that IT'S NOT ANONYMOUS!
ralphm
Anonymity is in the eye of the beholder?
Ge0rG
it's effectively adding a pseudonym for each bare JID in a MUC.
jonas’
my sarcasmometer isn’t sure about what you’re doing✎
Ge0rG
I'm not saying it's bad or wrong, just that the name doesn't fit.
jonas’
my sarcasmometer isn’t sure about what you’re saying ✏
ralphm
Ah, right.
jonas’
Ge0rG, you didn’t mention that yesterday
jonas’
but then again, MUC is pseudonymous in itself, it won’t get better than that?
ralphm
It would be better if that were more explicit.
Ge0rG
jonas’: it's a different kind of pseudonymous
ralphm
Anonymity for occupants v.s. admins, right?
Ge0rG
one could hash (muc-jid, nickname, bare-user-jid) together to allow nick changes to become identity changes.
Ge0rG
jonas’: I didn't mention it because it was not critical for what the XEP is supposed to do
pep.
Ge0rG, I think one of the goal is not to include nick in there✎
pep.
Ge0rG, I think one of the goals is not to include nick in there ✏
pep.
But yeah that could be made explicit
Ge0rG
I still think that making it a proxy-JID on top of the MUC service domain would be a Good Thing™, and then just stuff it into messages and presence.
jonas’
Ge0rG, ITYM making MIX?
ralphm
This
pep.
Ge0rG, I also have something like that in mind
pep.
But it's not incompatible
jonas’
are you going to re-invent MIX in worse on top MUC?
ralphm
I think doing MIX is a much better use of time than attempting to bolt things onto MUC even further.
pep.
worse? Last time I checked proxy-JID wasn't particularly pretty in MIX, trying to fix 4 things into 3 (is that the one?)✎
pep.
worse? Last time I checked proxy-JID wasn't particularly pretty in MIX, trying to fit 4 things into 3 (is that the one?) ✏
Ge0rG
pep.: yeah, it's the one
jonas’
pep., you’ll end up in the same situation with MUC, plus the additional issues from the different participant model
ralphm
Of course a MIX service could still expose a MUC interface/facade.
Ge0rG
ralphm: I'm fighting hard to keep that a thing, yes.
Ge0rG
I agree that proxy-JID is one of the uglier things of MIX.
jonas’
pep., the protoxep wants the occupant-id to be stable across rejoins. putting it on the domain then requires to make it reversible (so a simple HMAC won’t do, you eithre need to encrypt it symmetrically (not feasible) or store the mapping (ew))
Ge0rG
now that I think about it. Advertising those proxy JIDs inside of MUC will add a bunch of problems indeed, like clients trying to PM those JIDs
Ge0rG
it was a dumb idea, nevermind.
igoosehas joined
jonas’
Ge0rG, excellent, problem solved ;)
ralphm
Yay
Ge0rG
I just hate UUIDs for their uglyness.
pep.
jonas’, putting what on the domain
Zash
Where are there UUIDs?
pep.
Is that a remake of yesterday's discussion in programming@
Ge0rG
I suggest HMAC(server_secret, muc-JID + user-bare-JID)
Ge0rG
Zash: "UUID" is a placeholder for "long, random-looking hexadecimal string"
ralphm
Also, who cares. It is not something the user should ever see.
pep.
Ge0rG, HMAC(real_bare_jid, room_secret) is what I use in the module atm
ralphm
Someone should use emoji for hex digits
Ge0rG
pep.: that requires persisting the room_secret, whereas with a server_secret + room-JID you reduce the storage reqs
pep.
jonas’, see I said somebody would care about that :P
Ge0rG
ralphm: did you just say "usability nightmare"?
pep.
I just didn't know how to do that with prosody's API, but I don't really mind :)
Zash
Ge0rG room destruction and recreation would produce the same IDs then, which seems undesirable
okay, you could also rotate the room_secret on jid visibility changes.
Ge0rG
(as if anybody would do those in practice)
pep.
what does that mean
jonas’
Ge0rG, I prefer a room secret managed by the server, because it fixes destroy/re-create use cases
jonas’
Ge0rG, plus it avoids having to have the secret configurable / have a server/domain-wide secret which needs to be managed somehow
Ge0rG
jonas’: what's the threat model in those cases?
jonas’
Ge0rG, take a destroyed room, make it full-anon to lure folks back in (clients could warn if it isn’t anon/anon-mode changed between joins), note occupant-IDs, revert to non-anon✎
Ge0rG
I create a MUC, invite everybody there, store the occupant-id mappings, close down the MUC and let somebody else recreate it?
jonas’
Ge0rG, take a destroyed room, re-create it becoming owner, make it full-anon to lure folks back in (clients could warn if it isn’t anon/anon-mode changed between joins), note occupant-IDs, revert to non-anon ✏
Ge0rG
full-anon has been removed, hasn't it?
jonas’
Ge0rG, I call "occupant-id anon" "full anon"
jonas’
when we assume the path towards where the owner cannot see the real JID anymore, instead operating on the occupant-id
Ge0rG
jonas’: your naming convention needs more thought
jonas’
Ge0rG, sorry
Ge0rG
I might have mentioned it before, but none of this is actually anon.
jonas’
yes
jonas’
full-pseudonymous then ;)
pep.
That's also something I'd like to see, using occupant-id instead of real-jids to do MUC operations (even for owners)
valohas left
valohas joined
jonas’
Ge0rG, admittedly, I’m a bit thinking ahead here, but I think it’s valuable to do that
Ge0rG
pep.: we can hardly manage affiliation management in our clients with the existing protocol.
Syndacehas left
pep.
Fix your client?
Ge0rG
jonas’: what's the additional attack surface compared to "make a full-pseudo room full of people non-anon"
winfriedhas left
winfriedhas joined
jonas’
Ge0rG, you need to be owner to do that
Ge0rG
jonas’: yes, like in your proposed scenario
pep.
tbh if we were to start using occupant-id for more things, I'd prefer that to be a component setting and not a room setting that the owner can change
Ge0rG
pep.: what to be a component setting?
rion
The problem I see in SIMS is jingle transfer with references like this
<reference xmlns='urn:xmpp:reference:0' type='data' uri='xmpp:romeo@montague.lit/resource?jingle-ft' />
While they look quite simple to handle this "resource" part makes it very temporary. While it can be intended to have a temporary share it doesn't look quite reliable anyway. So a client to download a file should try all possible resources and expect the jingle session will be rejected immediately if the resource doesn't have this file. I'm not sure how it can't be enhanced, but probably there is a way (likely something with carbons).
As far as I understand Jingle session publishing suffers from the same problem. We have to send <start> request to specific resource, but which one?
rion
And with MUCs things are even more complicated.
pep.
Ge0rG, "use occupant-id for things", as said above (using it for MUC operations instead of real-jids)
alacerhas left
alacerhas joined
Ge0rG
pep.: so you want to be able to enforce occupant-id-stamping on all MUCs of your service?
Kev
> pep.
10:42
That's also something I'd like to see, using occupant-id instead of real-jids to do MUC operations (even for owners)
That would be broken, wouldn't it? You would need someone to join the room first before you could ever ban them.
Kev
And you wouldn't be able to ban other than single users.
tom
what if someone is set on harassing a muc
tom
and start creating a whole bunch of free accounts on a host
Ge0rG
tom: they'll just register new accounts via IBR
Ge0rG
...on different hosts
tom
and you can't preactively ban
Ge0rG
there's that script that will register thousands of IBR accounts on hundreds of servers for you.
tom
how can we metigate that?
Ge0rG
we can hope that the abusers won't find out
tom
so is this like an open resolvers on the internet type situation?
Kev
More or less, yes.
tom
oh no.
tom
nevermind
APachhas left
Nekithas left
frainzhas left
APachhas joined
frainzhas joined
lskdjfhas joined
Nekithas joined
alacerhas left
pep.
Kev, you can use mod_firewall for that. Or you can ask the server operator.
pep.
(well in both cases it's up to the server operator)
pep.
I'm not saying banning a real-jid wouldn't be possible anymore, I just don't feel the need to expose them
Kev
I don't understand the motivation, though. Suggesting mod_firewall, or other things the server operator needs to do, seems to be moving away from a functional standard mechanism, and that's kinda what we do.
pep.
handling spam is not really well spec'd tbh
pep.
And I don't think it's ever possible to do
Kev
I don't think banning people is necessarily about spam.
Unless you get really radical, technology usually doesn't solve social problems. Merely mitigates, or permanently removes the opponent from the equation. The latter is where Geneva is often mentioned.
Ge0rG
Let's give up and farm potatoes.
ralphm
You've never been in the Netherlands?
Ge0rG
ralphm: It'd be interesting to have a way to accomplish that... over the Internet.
Ge0rG
OTOH, there are underground groups with pre-made lists-of-opponents-to-be-removed, so I'm less prepared than they are, and their lists have all the wrong people on them.
Ge0rG
And without being able to properly execute, I shouldn't utter this kind of wish.
ralphm
...
pdurbinhas left
pep.
Is there an xmpp logo in svg somewhere?
pep.
Ah on the main page
adityaborikarhas left
pdurbinhas joined
adityaborikarhas joined
igoosehas left
pdurbinhas left
igoosehas joined
Zashhas left
krauqhas left
krauqhas joined
matlaghas left
matlaghas joined
kokonoehas left
valohas left
kokonoehas joined
COM8has joined
COM8has left
lnjhas joined
flowhas left
valohas joined
adityaborikarhas left
patrickhas joined
Chobbeshas joined
flowhas joined
eevvoorhas joined
alacerhas left
andrey.ghas left
ziggyshas joined
Zashhas joined
Chobbeshas left
Chobbeshas joined
adityaborikarhas joined
Chobbeshas left
Chobbeshas joined
Chobbeshas left
andrey.ghas joined
nyco
Board meeting -10 min
MattJ
o/
nyco
time+1
nyco
where's the gavel?
ralphmbangs gavel
ralphm
0. Welcome
ralphm
Who do we have?
Sevesays hi.
MattJ
Hey
nyco
bonjour
ralphm
Hi!
Guus
I'm on a very unreliable network
ralphm
:-D
ralphm
1. Minute taker
Guus
I might drop at any time, for any period
nyco
if nobody wants it, I'll do it
ralphm
2. Badges
ralphm
Poll results yet?
nyco
not sent yet, was waiting for more feedback: are we ok to go?
nyco
https://forms.gle/nY76DLaD6Ttyn8AV9 latest iteration, DO NOT VOTE YET
ralphm
I think so
nyco
if no red light today, I'll send it to members@ after I send the minutes
edhelashas left
MattJ
sgtm
edhelashas joined
ralphm
But I'm a bit confused. You didn't really add more questions per dwd's suggestion?
nyco
yes, I did, second page
ralphm
Oh!
nyco
first page is the choice + comment
ralphm
Yes, I see it now
ralphm
Looks good to me
dwd
LGTM2.
nyco
ok, thx all
Seve
Nice!
ralphm
Thanks, nyco!
dwd
So disappointed it's "badges" and not "badgers" though.
ralphm
:-D
ralphm
3. Messenger Regulation
ralphm
I'm sure it's holiday season, so nothing to report here?
leehas left
ralphm
Ge0rG
Ge0rG
ralphm: I still haven't written that promised mail to members@
Ge0rG
the contact person was very much interested in e2ee btw.
Ge0rG
also promised to come back to me in the timeframe of two months, which isn't over yet.
Ge0rG
our task of determining what exactly we expect is still open
Ge0rG
or rather what we want
ralphm
I think the first goal is give them the executive summary of what XMPP is
Ge0rG
maybe one of the XSF sposors would stand up to sponsor some heavy lobbying? ;)
Ge0rG
ralphm: that I did.
Ge0rG
ralphm: we have been listed as one of the stakeholders in the process.
ralphm
Good
waqashas joined
edhelashas left
Ge0rG
so what is our desired outcome? put XMPP into law? put "standardized protocol" into law?
nyco
well what other protocol qualifies?
nyco
no one sane recommands SIP/SIMPLE
nyco
Matrix is in its infancy
Ge0rG
nyco: matrix has been accelerating their standardization efforts
Ge0rG
nyco: the only difference between matrix and xmpp, for an outside observer, is some rfc numbers
nyco
Telegram protocol is quite not open nor standard, although openly documented, only one server implem
ralphm
The thing I find most important in general was summarized perfectly by Google (https://developers.google.com/talk/open_communications): Freedom of Client, Service, Platform.
Nekithas left
Nekithas joined
Ge0rG
ralphm: from when is that? 2004?
nyco
Matrix has only one server implem, thus does not qualify as an open standard
ralphm
Ge0rG: slightly later
Ge0rG
nyco: I think you are mixing up things there.
ralphm
Ge0rG: But it is indeed timeless
nyco
to be honest, we can push open standards protocols, but only one qualifies
Ge0rG
nyco: this is a classic approach, to make the requirements appear generic but be sufficiently specific so that only your proposal matches.
Ge0rG
still, Microsoft Open Office XML is the mandatory reference here.
nyco
athough I am biaised, you gotta be honest: what other protocol qualifies? none
Ge0rG
I'm sure that if pushed by legal regulations, Facebook, Google and the others will all come up with their own "open" "standard"
Ge0rG
...overnight
nyco
Note: have to leave exactly at 16:00
pep.
nyco, personally I wouldn't want to put a protocol name in the legislation
nyco
pep. this, I agree
ralphm
Ge0rG: indeed, the things we have going for us: standardized at IETF, many implementation, not a single entity in control
MattJ
I think we can all agree on that
ralphm
ss
pep.
Ge0rG, that will happen and I don't think there's anything you can do about this
Ge0rG
pep.: it's possible to make law that leaves the specific protocols open for a later decree.
nyco
the RGI name protocols (Référentiel Général d'Interopérabilité) in France
Ge0rG
pep.: we might have to create wording that, in the presence of malicious actors, can't be gamed too much
ralphm
Even if you'd mandate 'XMPP', what does that mean?
pep.
RFC3920!
nyco
we must then clearly define what an open standard is, and then different actors will push their agendas
ralphm
I think what you'd want is interop in features, retaining the freedoms I (Google) listed.
nyco
https://en.wikipedia.org/wiki/Open_standard
Zash
Exactly what Google deployed in 2006, no more, no less
ralphm
This will be fluid over time.
ralphm
Zash: with various notes, to be honest
Ge0rG
so how do we move forward now?
nyco
(time -5 min for me to leave)
Alexhas left
ralphm
Does it make sense to try to push what I wrote above, and showing how XMPP would get us there?
Ge0rG
we also should prepare an answer for E2EE over bridges.
MattJ
I think so
pep.
Ge0rG, "it doesn't work"? :/
ralphm
FWIW, full interop is never going to happen. There will always be features only certain implementations support. Establishing a baseline is not easy, but maybe our compliance suites could be a guide.
pep.
The best example of E2EE over bridges we have is OTR..
Ge0rG
which reminds me of things I need to put onto next Council's agenda.
Chobbeshas joined
edhelashas joined
Ge0rG
pep.: OTR is also the worst example.
ralphm
Ge0rG: bridges between XMPP and other networks (e.g. Matrix)?
pep.
Ge0rG, agreed
nyco
and IRC
Ge0rG
ralphm: if you mandate open access to facebook, whatsapp etc over xmpp, it will be some kind of bridge as well
nyco
on their side
Ge0rG
even if the bridging part is hidden from us
ralphm
I'd also note that although both XMPP and Matrix have federation features, making it a single federation is hard.
nyco
gotta go, sorry, I'm off
ralphm
nyco: thanks@
Ge0rG
do we want to mandate OMEMO in all IM clients? Or rather wait for / influence MLS?
Lancehas joined
ralphm
Ge0rG: well, I assume that Facebook, WhatsApp would expose their services as an XMPP server.
ralphm
I.e. the interop would be XMPP s2s
Ge0rG
ralphm: this is not an answer to E2EE
ralphm
Indeed, you'd need to agreed on protocol agnostic E2EE. I don't know if that's possible.
igoosehas left
Ge0rG
ralphm: either that, or all providers need to implement a protocol-specific E2EE algo in all their clients
Ge0rG
which is not impossible, if properly agreed upon by all parties
ralphm
Why couldn't you specify an E2EE mechanism like how SASL is defined?
Ge0rG
ralphm: please explain
ralphm
I.e. you can do SASL over IMAP, XMPP, and others.
ziggyshas left
ralphm
The interactions are defined, the wire protocol framing is a specialization
ralphm
Where things get hard is encrypting more than just text.
ralphm
If whatever you encrypt needs to be distributedly extensible, you need to agree to, basically, XMPP stanzas.
valohas left
igoosehas joined
ralphm
I think we can continue this discussion, but I'd also close the formal part of this meeting.
ralphm
5. Date of Next
ralphm
+1W
ralphm
6. Close.
ralphm
KTXBYE
MattJ
Thanks!
ralphmbangs gavel
Seve
Thank you :)
ralphm
Ge0rG: is it clear what I meant?
Alexhas joined
valohas joined
Ge0rG
ralphm: yes, thanks.
eevvoorhas left
ralphm
I suppose you could also define a JSON format that can then be encrypted, but if you want distributed extensibility, you need namespaces, etc., and you are basically replacing angle brackets with curly ones.
Ge0rG
I wonder if OMEMO isn't already 90% there
ralphm
I think DE is also a selling point to reluctant corps
Guus
I love this WiFi. Good meeting! Ttyl
pep.
Ge0rG, but not really appealing. I'm not sure I want to get stuck with only encrypted body in the legislation
Ge0rG
if only somebody had told the XEP authors.
pep.
And if you want more, as ralphm says, you have to have the same transport on the other side basically
pep.
Ge0rG, well OMEMO or not that's what you're saying, and that's effectively the only thing that can go over bridges (body-only)
ralphm
Guus: :-/
Ge0rG
pep.: OMEMO is what's there in XMPP land. There is also MLS of which I have no clue.
ralphm
pep.: same transport (XMPP s2s) would be ideal. For E2EE you need a common format to encrypt.
Ge0rG
pep.: and I'm sure we can easily embed XML or JSON or whatever inside OMEMO payloads
pep.
Ge0rG, and then you'd need clients to put encrypted json in body? :(
ralphm
pep.: and if you want Distributed Extensibility within that encrypted payload, then you might as well mandate XML Stanzas
Ge0rG
pep.: into the new OMEMO element.
Ge0rG
ralphm: at which point we arrive at Stanza Encryption
pep.
Ge0rG, I'm not sure I follow
pep.
You're not talking about stanza encryption yet?
Ge0rG
no idea what we are talking about
ralphm
We were talking about how E2EE might work across networks.
ralphm
E.g. Facebook, WhatsApp, 'normal' XMPP clients
ralphm
And I tried to list requisites, given that I assume both we and Facebook would want to be able to encrypt more than just plain text.
Ge0rG
I'm not sure how much the second part of that assumption holds.
Ge0rG: that's why I mentioned distributed extensibility. If each vendor has the ability to add their own stuff, you are not limiting a feature set.
ralphm
Of course whether other clients can interpret all the things is another matter.
Ge0rG
ralphm: I think you just invented the XSF
ralphm
But you'd definitely need to have a baseline (probably plain text)
ralphm
Not even the XSF needs to be a single controlling entity.
ralphm
At VEON, we clearly defined all rich messaging in a way that it could have a fallback body with plain text.
Ge0rG
I wish XEP authors would consider that.
ralphm
Aren't you on the Council?
Ge0rG
Each rich messaging XEP should:
- mandate a legacy body format
- mandate that the body MUST NOT contain anything else, so that compliant clients can ignore it
ralphm
Make it one of your review checkboxes.
Ge0rG
ralphm: you'd be surprised, it already is
ralphm
I'd hoped so. It was definitely on mine.
Ge0rG
unfortunately I'm not aware of any XEP that follows this simple pattern
Nekithas left
Ge0rG
not even EME
Ge0rG
> When a message is marked with an encryption tag and can not be decrypted, the body can safely be ignored and a localized message displayed instead.
This is close, but not quite there.
Nekithas joined
ralphm
No?
ralphm
XHTML-IM?
ralphm
References, and thus SIMS, also assume this.
Zash
So when are we un-deprecating XHTML-IM again?
ralphm
No, I'm saying that the way it was designed, it assumes that if you don't support it, you can still use the body.
ralphm
Without loss of information ideally.
ralphm
Also, XEP-0060, section 12.7 (and other places).
Ge0rG
ralphm: indeed, XHTML-IM is explicit in that regard. I'm not sure I would count References as it's only an annotation to <body>, not a replacement.
waqashas left
ralphm
Sure, but the idea here is entirely that the common format is plain text, and that richer stuff points to it.
ralphm
(sure, you can also use References with actually referencing begin/end, but that'd mean you lose information)
ralphm
without
Ge0rG
I'm looking at XEPs that contain a fallback <body> for non-supporting clients, and that should mandate that the <body> will be superseded
Ge0rG
OOB as currently used is the best anti-pattern example to that.
Ge0rG
the new reactions proto-proto-XEP fails miserably as well
Ge0rG
and then there are things like MUC invitations (direct or mediated)
adityaborikarhas left
adityaborikarhas joined
ralphm
I haven't read that yet, but reactions should be annotations. A body might be tricky. I'm not sure how to refer to a previous message in plain text in a way that a user could understand.
In case a body cannot convey a certain extension, maybe it could say something to that effect.
Ge0rG
I sent you an OMEMO encrypted message but your client doesn’t seem to support that. Find more information on https://conversations.im/omemo
ralphm
'You are invited to a chat room, but your client doesn't support this mechanism. [link-to-faq-page].
ralphm
See, literally the same thing.
debaclehas left
ralphm
(oh, and a closing ')
Ge0rG
ralphm: technically, an OMEMO client could insert actual text into the <body> of an OMEMO message, and it would remain unnoticed by OMEMO clients.
pdurbinhas joined
Ge0rG
https://xmpp.org/extensions/xep-0384.html doesn't mandate that the <body> must be throw-away content
Ge0rG
> If the decryption fails, the client MUST silently discard the OMEMO message. If it succeeds, the decrypted contents are treated as the <body> of the received message.
ralphm
Given that it is not Final, there's some room still :-D
Ge0rG
So I could troll OMEMO-enabled clients by adding a broken <encrypted xmlns='eu.siacs.conversations.axolotl'> element into all my messages.
debaclehas joined
Lancehas left
ralphm
There are so many ways to troll clients. Again, social problems.
Ge0rG
ralphm: I'm pretty sure that XEP won't move forward in the current state ;)
Ge0rG
when designing the receiving side of things, I need to make a deliberate decision on throwing away the <body>
Ge0rG
I suppose I'm way too deep in nitpicking mode.
adityaborikarhas left
adityaborikarhas joined
ralphm
:-)
ralphm
:-)
pdurbinhas left
ziggyshas joined
lnjhas left
lnjhas joined
adityaborikarhas left
adityaborikarhas joined
Lancehas joined
curenhas left
nyco
minutes sent
nyco
poll sent
Ge0rG
can I vote now? :D
Lance
MattJ: hats ping
nyco
Ge0rG only once! :)
Ge0rG
only once per split identity.
nyco
ah, this...
nyco
if these people are many contributors, then yes
Ge0rG
nyco: you forgot to add the "would you use it?" to the poll.
nyco
second page
nyco
2) If you run an XMPP project, would you use those badges? (website, repo, doc, flyer, poster, etc.)
Ge0rG
👍
sezuanhas left
eevvoorhas joined
adityaborikarhas left
adityaborikarhas joined
UsLhas left
goffihas left
UsLhas joined
lovetoxhas joined
Chobbeshas left
Chobbeshas joined
Chobbeshas left
Chobbeshas joined
igoosehas left
igoosehas joined
debaclehas left
valohas left
valohas joined
igoosehas left
UsLhas left
pdurbinhas joined
igoosehas joined
waqashas left
pdurbinhas left
jjrhhas left
Nekithas left
moparisthebest
jonas’:
> The initiating party MUST NOT perform A/AAAA fallback as per &rfc6120; (since the service provider has already indicated that the SRV protocol is supported).
davidhas left
davidhas joined
moparisthebest
eh, I know what 6120 says but I can't agree with that here
moparisthebest
it's trivial for an evil attacker to insert a DNS record that tells a client/server not to fallback
moparisthebest
I see no harm in falling back anyway if you are doing TLS, does anyone?
moparisthebest
(sorry for ENOCONTEXT referencing https://github.com/xsf/xeps/pull/796/files )
Nekithas joined
moparisthebest
the other bit, trying regular _xmpp-client/_xmpp-server seems fine though
UsLhas joined
rion
about improving SIMS... I believe Jingle Session Publishing xep should take some features from Jingle Message Initiation then it will fit well to SIMS.
Like..
1. I'm sending SIMS with published Jingle session
2. a party discovers details of the published Jingle session and if it's compatible sends a *message* (not iq) with <start>
3. the message is carbonned and my other resources not having the file from SIMS just ignore the message (or maybe just record it happened)
4. my resource which has the file sends <starting> via message to a party resource so other my resources know I'm sending a file and also know where from
5. a party initiates jingle session with file request to specific resource (where <starting> came from)
ralphm
moparisthebest: I wrote this elsewhere before, but I disagree, too. See also RFC 2782. We should totally have a fallback, so the service name should be registered with IANA with a port number.
ralphm
Elsewhere being the mailing list
moparisthebest
yep I see that in the email chain now ralphm
ralphm
rion: could you send a mail on this, with maybe some example protocol exchange?
moparisthebest
I vaguely recall conversations daniel talking about falling back to 443, clearly we can't register that with IANA though
ralphm
rion: It is a bit hard to wrap my head around it.
moparisthebest
I actually don't mind either way if the XEP recommends to fallback and/or a port, I just strongly disagree with "MUST NOT fallback"
neshtaxmpphas left
rion
ralphm: yep. a little bit later. need to finish some regular work stuff first :)
ralphm
moparisthebest: I think that's not a great idea. However, one could use port 443 as an SRV target port.
ralphm
rion: 👍
ralphm
moparisthebest: right, I think we should prevent doing something special. I'd like to use existing generic SRV handlers.
UsLhas left
moparisthebest
especially when it's only downsides, basically just allowing a network MITM to keep you disconnected when there is a chance you could connect
jonas’
moparisthebest, an evil attacker can also insert a broken A/AAAA record
jonas’
if you assume that DNS can be meddled with, all bets are off
moparisthebest
right, should probably fallback then too
jonas’
fall back to what?
moparisthebest
everything you can
jonas’
there is nothing to fall back if your attacker spoofs A/AAAA
jonas’
you just end up with broken TLS, hopefully
moparisthebest
ah sorry I read that as 'broken SRV record' but yea
ralphm
jonas’: I don't think it is useful to think about spoofing DNS in this context.
jonas’
ralphm, indeed
ralphm
But following the RFC on SRV records seems sensible.
moparisthebest
I think it is though, you can't get around everything an evil mitm could do of course, but maybe you can get around some of them, and there is no reason to give up early
Zash
ralphm: So does that mean the "fetch both _xmpp and _xmpps SRV and merge the results" is undesirable?
ralphm
Yes
Zash
I tend to agree
moparisthebest
that is optional though
jonas’
moparisthebest, initiating connections the domain owner clearly did not intend you to do is probably not a good idea
jonas’
and this is what you’re doing in this case
jonas’
the endpoint you end up connecting to may easily be a hacked webserver for the same domain
jonas’
it may be in an entirely different trust domain. just don’t do things the domain owner asked you specifically not to do by placing SRV records.
moparisthebest
you have no guarantees that the SRV record came from the domain owner though
moparisthebest
unless DNSSEC, I'm fine with a MUST NOT if you've validated it with DNSSEC
jonas’
17:29:06 ralphm> jonas’: I don't think it is useful to think about spoofing DNS in this context.
jonas’
moparisthebest, ^
jonas’
if the attacker can spoof the SRV record, they can also spoof the A/AAAA you want to fall back to. it’s pointless.
moparisthebest
and I disagree with that :)
jonas’
what you propose does not help against an active DNS attacker, and it makes the situation worse in a non-attacked situation.
moparisthebest
because some attacker might just spoof the SRV record and not A/AAAA, or you might be getting A/AAAA over tor because that only supports them and not SRV
jonas’
(or in a situation where the attacker has control over a specific machine (A/AAAA), but not over DNS)
moparisthebest
or a million other reasons
goffihas joined
jonas’
moparisthebest, if you’re connecting via a transport which does not support SRV, then obviously XEP-0386 does not apply to you
Zash
Don't worry, be happy. Make sure you validate the TLS certificate.
moparisthebest
if domain owner is running a public web server that will be hurt by attempting a funky connection to it, they need to fix that
jonas’
and neither does the SRV RFC or the parts about SRV in RFC 6120
jonas’
moparisthebest, it may not be *hurt*, but it may easily log things to plaintext logs which you (as the client/user) wouldn’t want to have there. think pipelining authentication because you "know" the domain already.
igoosehas left
moparisthebest
SRV RFC is more generic, it doesn't know we have a foolproof way of validating the port we connect to by guessing
Zash
validating ... by guessing
moparisthebest
we guess the port
Nekithas left
jonas’
what?
moparisthebest
we have a foolproof way of validating whether it was correct or not, TLS certs
jonas’
no, that’s not foolproof
jonas’
the webserver or whatever on the A/AAAA record *will* have a TLS cert for *exactly* the domain
Nekithas joined
jonas’
so you’re on the wrong port, but still connected and TLS says everything’s green
moparisthebest
right, and that's fine
jonas’
no it’s not
Zash
400 WHAT ARE THESE ANGLE BRACKETS
Connection: gtfo
Zash
I still think guessing is stupid
jonas’
guessing is stupid and dangerous
moparisthebest
it absolutely is, again running a public port on the internet means you are willing to accept whatever garbage anyone throws at you
moparisthebest
and not only accept, but be happy about it
jonas’
moparisthebest, yes, and I might log that "garbage" including your SASL PLAIN password into some plaintext files for someone to investigate
neshtaxmpphas joined
jonas’
which is probably very much not what you want
jonas’
or alternatively, the webserver may run in a different trust domain and may be owned by an attacker
moparisthebest
the domain owner is the one that made a decision to give them a cert valid for xmpp, and to run an xmpp and https service on the same domain
moparisthebest
so the owner already decided all that was fine
jonas’
not really
jonas’
they have told you via SRV that you should very much should not connect to that webserver machine for XMPP
jonas’
anything you do beyond that is your fault
moparisthebest
again without DNSSEC you can't know that, you can only guess
jonas’
okay, the discussion has just become a pointless loop
moparisthebest
bottom line, as a user, I want to connect by any means possible, I certainly don't want to not connect because a network is poorly configured either intentionally or accidentally
moparisthebest
if I understand correctly, you are saying a domain/server operator might not want certain connections, and while I agree, that's tough shit
Nekithas left
moparisthebest
you open a public port on the internet you have to be willing to accept anything anyhow at any time, period
Nekithas joined
jjrhhas joined
Zash
so we have the two classic camps "fail early and hard on errors" and "just make it work at an ycost"
Zash
XML vs HTML
Zash
etc
moparisthebest
I dislike being compared to HTML but otherwise sure :D
Nekithas left
goffihas left
igoosehas joined
ralphm
If you want to prevent connections, you can publish an SRV record with . as target
Zash
Ask Ge0rG how common it still is for devices to not support SRV resolution
ralphm
Well, if that's true, they are not able to have functional compliant XMPP implementations.
Zash
I imagine the fault would most likely be in DNS resolvers in cheap routers or something
larmahas left
Holger
Or Tor.
ralphm
But wait, how does that prevent a client device from doing SRV? Or do you mean routers blocking SRV requests?
Zash
Blocking or otherwise failing for unknown reasons
moparisthebest
because a client generally gets their DNS server from DHCP which tells it to use crap router
Holger
WiFi routers having a built-in caching DNS server that's borked.
ralphm
Well, I'm not sure if I want to be in the business of catering for such brokenness.
jonas’
there’s also some firewall appliances which filter SRV away
Zash
And fallback combined with SRV not being critical for the web or email means nobody notices or fixes them.
moparisthebest
of course DoX fixes this if you have a hard-coded ip+port for your resolver :D
Holger
On the public servers I'm involved with, we'd loose >10% of the users by not redirecting 5222 from the A/AAAA target.
goffihas joined
Zash
Holger: Sounds like what Ge0rG has said about yax.im
ralphm
Holger: wow. Are those corporate users?
ralphm
Also, how can you tell.
Holger
ralphm: I don't think so; as I said, from what I've seen it's mostly crap end-user routers and Tor.
ralphm
Tor is not on my radar
ralphm
But how can you tell that users cannot use SRV?
Holger
ralphm: I just check the percentage of the connections that are redirected from the A/AAAA target.
ralphm
Oh, you publish a different host in SRV?
Holger
ralphm: Yes.
ralphm
I kinda want users to complain to their ISPs.
Holger
ralphm: Not sure about the Tor/crap-router ratio. But it's definitely not just Tor.
karoshihas left
Holger
ralphm: Well they'd have to complain to their router manufacturers. At least in the cases I tracked down.
Holger
(Which was like two or three.)
Holger
A popular thing in France was/is affected, for example.
moparisthebest
also just as a data point I have what I'd call a "crap corporate network" and SRV is wide open, but it'll only allow HTTP on 80 and TLS on 443, it checks that it's actually TLS too
larmahas joined
goffihas left
goffihas joined
moparisthebest
and yea it'd be great if people complained to ISP/router manufacturers, in practice though it's just "XMPP sucks I can't even connect"
Lancehas left
Sevehas left
Vaulorhas left
goffihas left
UsLhas joined
ralphm
Holger: in most cases people get routers from their ISP. If not, they have themselves to blame for broken behavior.
waqashas joined
Holger
True that.
Holger
Of course neither will stop them from concluding what moparisthebest said. XMPP fails, everything else just works.
Zash
Can't have nice things
ralphm
And corporate users, well, should complain to corporate IT. There's no end to stupidity in that area.
Zash
ENTERPRISE
moparisthebest
> Star Trek Fan Accidentally Accepts Job Writing "Enterprise Software"
ralphm
When we worked on Jingle/WebRTC we had some issues with blocked UDP traffic in our office.
moparisthebest
ralphm, don't worry QUIC should fix that for you in a bit :)
ralphm
Thus wasting valuable bandwidth for calls between two people in the office.
ralphm
moparisthebest: I think QUIC has a lot going for it, but no.
moparisthebest
Zash, I think it's more like "can only have nice things if HTTP wants them first" :D
Zash
:(
ralphm
moparisthebest: not in this case, I mean. I definitely would like to see XMPP-over-QUIC.
neshtaxmpphas left
wojtekhas joined
ralphm
And indeed if QUIC would work in the corporate environment, then calls would too, since you can use the same port for TURN/STUN.
moparisthebest
I mainly meant users will complain if websites quit working, so as websites migrate to http3/udp and break, networks should be fixing that
Lancehas joined
debaclehas joined
ralphm
I think websites will fallback to plain http for a long time
rion
QUIC+WebRTC ? I though wg abandoned this idea because all the id remapping crap for compatibility with STUN and absence of signalling ideas.
rion
thought*
ralphm
Sure, but I believe even without changes, it can still be done.
ralphm
Especially with XMPP, as hey, we have signaling.
ralphm
The conflict is with TURN mostly
wojtekhas left
eevvoorhas left
frainzhas left
frainzhas joined
ralphm
I am a bit surprised one of the arguments is that TURN is rarely used with WebRTC, though. TURN was considered a significant requirement when we were building calls in the VEON app.
Lancehas left
ralphm
But that's not on websites, so who cares? Right, fippo?
frainzhas left
igoosehas left
frainzhas joined
adityaborikarhas left
pdurbinhas joined
frainzhas left
frainzhas joined
igoosehas joined
igoosehas left
pdurbinhas left
frainzhas left
frainzhas joined
frainzhas left
frainzhas joined
Steve Killehas left
rion
If web browsers could use our signaling out of the box that would be quite interesting.
ralphm
Hah, well! If I'm right, the webrtc library has roots in libjingle.
ralphm
Of course with all the XMPP now removed.
Zash
ralphm: I have heard that as well
ralphm
Maybe we could say XMPP caused WebRTC to happen.
neshtaxmpphas joined
igoosehas joined
UsLhas left
frainzhas left
frainzhas joined
Lancehas joined
frainzhas left
frainzhas joined
tom
Shouldn't IPv6 fix these issues as well?
frainzhas left
tom
because with IPv6, if setup properly every computer on then network get's it's own unique publicly routable IPv6 address
tom
sometimes every device gets a whole range to itself
jonas’
> because with IPv6, if setup properly
jonas’
that’s the catch ;)
tom
well
jonas’
but yes, IPv6 will (hopefully) make mayn things easier✎
jonas’
but yes, IPv6 will (hopefully) make many things easier ✏
tom
most corporate enviroments are going to setup PFsense or OpenWRT
tom
which sets up most of ipv6 for you ounce you give it an upstream
frainzhas joined
igoosehas left
tom
we aren't in the dark ages of proprietary router firmware ruling majority anymore, least not for professional space
tom
too many routers got turned into zombies
jonas’
ironically, the gateway thing provided by my ISP handles IPv6 just fine
jonas’
it even supports prefix delegation via DHCPv6
ralphm
I think your view on the activities or competence of corporate IT departments is extremely optimistic.
tom
maybe that's just my area
Zash
PFsense? OpenWRT? NOT ENOUGH ENTERPRISE
frainzhas left
tom
the only place I've really seen something not PacketFilter of NetFilter based is where it's probably not possible to route/firewall without ASICs
jonas’
ralphm, that, too
tom
like routing 400+gbps
tom
where we'd use a switch fabric backplane
tom
otherwise everything in the office areas flowed threw a PFsense box.
tom
the 1U unit they sell
ralphm
You might have been lucky.
frainzhas joined
Sevehas joined
ralphm
I've seen IT departments being understaffed, underfunded, outsourced, and misused for setting up teleconferences.
goffihas joined
frainzhas left
frainzhas joined
Yagizahas left
moparisthebest
tom, can you tell my corporate IT dept, they use all the proprietary blackboxes, riverbed, telari, cisco, and palo alto
moparisthebest
and those are just the ones I know about
Vaulorhas joined
zachhas left
zachhas joined
Nekithas joined
Steve Killehas joined
Steve Killehas left
igoosehas joined
zachhas left
zachhas joined
remkohas left
frainzhas left
frainzhas joined
ziggyshas left
lovetox_has joined
lovetox_has left
frainzhas left
frainzhas joined
lskdjfhas left
lskdjfhas joined
igoosehas left
goffihas left
lumihas joined
igoosehas joined
pep.
"Ge0rG> Each rich messaging XEP should:
- mandate a legacy body format
- mandate that the body MUST NOT contain anything else, so that compliant clients can ignore it", I don't want to start a discussion right now (sleep!) but I also don't want to forget about it, so I'll say for now that I'm not sure I like this, and we can come back to it later :)
ralphm
Dude. I want to sleep.
waqashas left
Ge0rG
pep.: I'm going to write that to standards in the context of reactions