rionI'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
ZashWhat kind of improvements?
Ge0rGThe biggest issue I have with the occupant-id thing is that IT'S NOT ANONYMOUS!
ralphmAnonymity is in the eye of the beholder?
Ge0rGit's effectively adding a pseudonym for each bare JID in a MUC.
jonas’my sarcasmometer isn’t sure about what you’re doing
Ge0rGI'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
ralphmAh, 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?
ralphmIt would be better if that were more explicit.
Ge0rGjonas’: it's a different kind of pseudonymous
ralphmAnonymity for occupants v.s. admins, right?
Ge0rGone could hash (muc-jid, nickname, bare-user-jid) together to allow nick changes to become identity changes.
Ge0rGjonas’: 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
Ge0rGI 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?
ralphmThis
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?
ralphmI 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?)
Ge0rGpep.: 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
ralphmOf course a MIX service could still expose a MUC interface/facade.
Ge0rGralphm: I'm fighting hard to keep that a thing, yes.
Ge0rGI 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))
Ge0rGnow 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
Ge0rGit was a dumb idea, nevermind.
igoosehas joined
jonas’Ge0rG, excellent, problem solved ;)
ralphmYay
Ge0rGI just hate UUIDs for their uglyness.
pep.jonas’, putting what on the domain
ZashWhere are there UUIDs?
pep.Is that a remake of yesterday's discussion in programming@
Ge0rGZash: "UUID" is a placeholder for "long, random-looking hexadecimal string"
ralphmAlso, 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
ralphmSomeone should use emoji for hex digits
Ge0rGpep.: 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
Ge0rGralphm: 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 :)
ZashGe0rG room destruction and recreation would produce the same IDs then, which seems undesirable
pep.^this
pep.^ this
Ge0rGZash: is it really?
alacerhas left
alacerhas joined
Ge0rGokay, 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
Ge0rGjonas’: 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
Ge0rGI 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
Ge0rGfull-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
Ge0rGjonas’: your naming convention needs more thought
jonas’Ge0rG, sorry
Ge0rGI 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
Ge0rGpep.: we can hardly manage affiliation management in our clients with the existing protocol.
Syndacehas left
pep.Fix your client?
Ge0rGjonas’: 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
Ge0rGjonas’: 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
Ge0rGpep.: what to be a component setting?
rionThe 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?
rionAnd 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
Ge0rGpep.: 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.
KevAnd you wouldn't be able to ban other than single users.
tomwhat if someone is set on harassing a muc
tomand start creating a whole bunch of free accounts on a host
Ge0rGtom: they'll just register new accounts via IBR
Ge0rG...on different hosts
tomand you can't preactively ban
Ge0rGthere's that script that will register thousands of IBR accounts on hundreds of servers for you.
tomhow can we metigate that?
Ge0rGwe can hope that the abusers won't find out
tomso is this like an open resolvers on the internet type situation?
KevMore or less, yes.
tomoh no.
tomnevermind
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
KevI 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
KevI don't think banning people is necessarily about spam.
pep.And that feature wouldn't go away
pep.And this feature wouldn't go away
frainzhas left
Syndacehas joined
frainzhas joined
Ge0rGwe have blocking, but it doesn't work for MUCs
ZashTechnical solutions to social problems?
igoosehas left
alacerhas joined
pdurbinhas joined
adityaborikarhas left
adityaborikarhas joined
igoosehas joined
ralphmSo much this
ralphmUnless 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.
Ge0rGLet's give up and farm potatoes.
ralphmYou've never been in the Netherlands?
Ge0rGralphm: It'd be interesting to have a way to accomplish that... over the Internet.
Ge0rGOTOH, 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.
Ge0rGAnd 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
nycoBoard meeting -10 min
MattJo/
nycotime+1
nycowhere's the gavel?
ralphmbangs gavel
ralphm0. Welcome
ralphmWho do we have?
Sevesays hi.
MattJHey
nycobonjour
ralphmHi!
GuusI'm on a very unreliable network
ralphm:-D
ralphm1. Minute taker
GuusI might drop at any time, for any period
nycoif nobody wants it, I'll do it
ralphm2. Badges
ralphmPoll results yet?
nyconot sent yet, was waiting for more feedback: are we ok to go?
nycohttps://forms.gle/nY76DLaD6Ttyn8AV9 latest iteration, DO NOT VOTE YET
ralphmI think so
nycoif no red light today, I'll send it to members@ after I send the minutes
edhelashas left
MattJsgtm
edhelashas joined
ralphmBut I'm a bit confused. You didn't really add more questions per dwd's suggestion?
nycoyes, I did, second page
ralphmOh!
nycofirst page is the choice + comment
ralphmYes, I see it now
ralphmLooks good to me
dwdLGTM2.
nycook, thx all
SeveNice!
ralphmThanks, nyco!
dwdSo disappointed it's "badges" and not "badgers" though.
ralphm:-D
ralphm3. Messenger Regulation
ralphmI'm sure it's holiday season, so nothing to report here?
leehas left
ralphmGe0rG
Ge0rGralphm: I still haven't written that promised mail to members@
Ge0rGthe contact person was very much interested in e2ee btw.
Ge0rGalso promised to come back to me in the timeframe of two months, which isn't over yet.
Ge0rGour task of determining what exactly we expect is still open
Ge0rGor rather what we want
ralphmI think the first goal is give them the executive summary of what XMPP is
Ge0rGmaybe one of the XSF sposors would stand up to sponsor some heavy lobbying? ;)
Ge0rGralphm: that I did.
Ge0rGralphm: we have been listed as one of the stakeholders in the process.
ralphmGood
waqashas joined
edhelashas left
Ge0rGso what is our desired outcome? put XMPP into law? put "standardized protocol" into law?
nycowell what other protocol qualifies?
nycono one sane recommands SIP/SIMPLE
nycoMatrix is in its infancy
Ge0rGnyco: matrix has been accelerating their standardization efforts
Ge0rGnyco: the only difference between matrix and xmpp, for an outside observer, is some rfc numbers
nycoTelegram protocol is quite not open nor standard, although openly documented, only one server implem
ralphmThe 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
Ge0rGralphm: from when is that? 2004?
nycoMatrix has only one server implem, thus does not qualify as an open standard
ralphmGe0rG: slightly later
Ge0rGnyco: I think you are mixing up things there.
ralphmGe0rG: But it is indeed timeless
nycoto be honest, we can push open standards protocols, but only one qualifies
Ge0rGnyco: this is a classic approach, to make the requirements appear generic but be sufficiently specific so that only your proposal matches.
Ge0rGstill, Microsoft Open Office XML is the mandatory reference here.
nycoathough I am biaised, you gotta be honest: what other protocol qualifies? none
Ge0rGI'm sure that if pushed by legal regulations, Facebook, Google and the others will all come up with their own "open" "standard"
Ge0rG...overnight
nycoNote: have to leave exactly at 16:00
pep.nyco, personally I wouldn't want to put a protocol name in the legislation
nycopep. this, I agree
ralphmGe0rG: indeed, the things we have going for us: standardized at IETF, many implementation, not a single entity in control
MattJI think we can all agree on that
ralphmss
pep.Ge0rG, that will happen and I don't think there's anything you can do about this
Ge0rGpep.: it's possible to make law that leaves the specific protocols open for a later decree.
nycothe RGI name protocols (Référentiel Général d'Interopérabilité) in France
Ge0rGpep.: we might have to create wording that, in the presence of malicious actors, can't be gamed too much
ralphmEven if you'd mandate 'XMPP', what does that mean?
pep.RFC3920!
nycowe must then clearly define what an open standard is, and then different actors will push their agendas
ralphmI think what you'd want is interop in features, retaining the freedoms I (Google) listed.
nycohttps://en.wikipedia.org/wiki/Open_standard
ZashExactly what Google deployed in 2006, no more, no less
ralphmThis will be fluid over time.
ralphmZash: with various notes, to be honest
Ge0rGso how do we move forward now?
nyco(time -5 min for me to leave)
Alexhas left
ralphmDoes it make sense to try to push what I wrote above, and showing how XMPP would get us there?
Ge0rGwe also should prepare an answer for E2EE over bridges.
MattJI think so
pep.Ge0rG, "it doesn't work"? :/
ralphmFWIW, 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..
Ge0rGwhich reminds me of things I need to put onto next Council's agenda.
Chobbeshas joined
edhelashas joined
Ge0rGpep.: OTR is also the worst example.
ralphmGe0rG: bridges between XMPP and other networks (e.g. Matrix)?
pep.Ge0rG, agreed
nycoand IRC
Ge0rGralphm: if you mandate open access to facebook, whatsapp etc over xmpp, it will be some kind of bridge as well
nycoon their side
Ge0rGeven if the bridging part is hidden from us
ralphmI'd also note that although both XMPP and Matrix have federation features, making it a single federation is hard.
nycogotta go, sorry, I'm off
ralphmnyco: thanks@
Ge0rGdo we want to mandate OMEMO in all IM clients? Or rather wait for / influence MLS?
Lancehas joined
ralphmGe0rG: well, I assume that Facebook, WhatsApp would expose their services as an XMPP server.
ralphmI.e. the interop would be XMPP s2s
Ge0rGralphm: this is not an answer to E2EE
ralphmIndeed, you'd need to agreed on protocol agnostic E2EE. I don't know if that's possible.
igoosehas left
Ge0rGralphm: either that, or all providers need to implement a protocol-specific E2EE algo in all their clients
Ge0rGwhich is not impossible, if properly agreed upon by all parties
ralphmWhy couldn't you specify an E2EE mechanism like how SASL is defined?
Ge0rGralphm: please explain
ralphmI.e. you can do SASL over IMAP, XMPP, and others.
ziggyshas left
ralphmThe interactions are defined, the wire protocol framing is a specialization
ralphmWhere things get hard is encrypting more than just text.
ralphmIf whatever you encrypt needs to be distributedly extensible, you need to agree to, basically, XMPP stanzas.
valohas left
igoosehas joined
ralphmI think we can continue this discussion, but I'd also close the formal part of this meeting.
ralphm5. Date of Next
ralphm+1W
ralphm6. Close.
ralphmKTXBYE
MattJThanks!
ralphmbangs gavel
SeveThank you :)
ralphmGe0rG: is it clear what I meant?
Alexhas joined
valohas joined
Ge0rGralphm: yes, thanks.
eevvoorhas left
ralphmI 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.
Ge0rGI wonder if OMEMO isn't already 90% there
ralphmI think DE is also a selling point to reluctant corps
GuusI 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
Ge0rGif 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)
ralphmGuus: :-/
Ge0rGpep.: OMEMO is what's there in XMPP land. There is also MLS of which I have no clue.
ralphmpep.: same transport (XMPP s2s) would be ideal. For E2EE you need a common format to encrypt.
Ge0rGpep.: 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? :(
ralphmpep.: and if you want Distributed Extensibility within that encrypted payload, then you might as well mandate XML Stanzas
Ge0rGpep.: into the new OMEMO element.
Ge0rGralphm: 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?
Ge0rGno idea what we are talking about
ralphmWe were talking about how E2EE might work across networks.
ralphmGe0rG: 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.
ralphmOf course whether other clients can interpret all the things is another matter.
Ge0rGralphm: I think you just invented the XSF
ralphmBut you'd definitely need to have a baseline (probably plain text)
ralphmNot even the XSF needs to be a single controlling entity.
ralphmAt VEON, we clearly defined all rich messaging in a way that it could have a fallback body with plain text.
Ge0rGI wish XEP authors would consider that.
ralphmAren't you on the Council?
Ge0rGEach 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
ralphmMake it one of your review checkboxes.
Ge0rGralphm: you'd be surprised, it already is
ralphmI'd hoped so. It was definitely on mine.
Ge0rGunfortunately I'm not aware of any XEP that follows this simple pattern
Nekithas left
Ge0rGnot 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
ralphmNo?
ralphmXHTML-IM?
ralphmReferences, and thus SIMS, also assume this.
ZashSo when are we un-deprecating XHTML-IM again?
ralphmNo, I'm saying that the way it was designed, it assumes that if you don't support it, you can still use the body.
ralphmWithout loss of information ideally.
ralphmAlso, XEP-0060, section 12.7 (and other places).
Ge0rGralphm: 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
ralphmSure, 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)
ralphmwithout
Ge0rGI'm looking at XEPs that contain a fallback <body> for non-supporting clients, and that should mandate that the <body> will be superseded
Ge0rGOOB as currently used is the best anti-pattern example to that.
Ge0rGthe new reactions proto-proto-XEP fails miserably as well
Ge0rGand then there are things like MUC invitations (direct or mediated)
adityaborikarhas left
adityaborikarhas joined
ralphmI 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.
ralphmIn case a body cannot convey a certain extension, maybe it could say something to that effect.
Ge0rGI 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].
ralphmSee, literally the same thing.
debaclehas left
ralphm(oh, and a closing ')
Ge0rGralphm: 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
Ge0rGhttps://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.
ralphmGiven that it is not Final, there's some room still :-D
Ge0rGSo 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
ralphmThere are so many ways to troll clients. Again, social problems.
Ge0rGralphm: I'm pretty sure that XEP won't move forward in the current state ;)
Ge0rGwhen designing the receiving side of things, I need to make a deliberate decision on throwing away the <body>
Ge0rGI 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
nycominutes sent
nycopoll sent
Ge0rGcan I vote now? :D
LanceMattJ: hats ping
nycoGe0rG only once! :)
Ge0rGonly once per split identity.
nycoah, this...
nycoif these people are many contributors, then yes
Ge0rGnyco: you forgot to add the "would you use it?" to the poll.
nycosecond page
nyco2) 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
moparisthebestjonas’:
> 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
moparisthebesteh, I know what 6120 says but I can't agree with that here
moparisthebestit's trivial for an evil attacker to insert a DNS record that tells a client/server not to fallback
moparisthebestI 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
moparisthebestthe other bit, trying regular _xmpp-client/_xmpp-server seems fine though
UsLhas joined
rionabout 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)
ralphmmoparisthebest: 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.
ralphmElsewhere being the mailing list
moparisthebestyep I see that in the email chain now ralphm
ralphmrion: could you send a mail on this, with maybe some example protocol exchange?
moparisthebestI vaguely recall conversations daniel talking about falling back to 443, clearly we can't register that with IANA though
ralphmrion: It is a bit hard to wrap my head around it.
moparisthebestI 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
rionralphm: yep. a little bit later. need to finish some regular work stuff first :)
ralphmmoparisthebest: I think that's not a great idea. However, one could use port 443 as an SRV target port.
ralphmrion: 👍
ralphmmoparisthebest: right, I think we should prevent doing something special. I'd like to use existing generic SRV handlers.
UsLhas left
moparisthebestespecially 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
moparisthebestright, should probably fallback then too
jonas’fall back to what?
moparisthebesteverything you can
jonas’there is nothing to fall back if your attacker spoofs A/AAAA
jonas’you just end up with broken TLS, hopefully
moparisthebestah sorry I read that as 'broken SRV record' but yea
ralphmjonas’: I don't think it is useful to think about spoofing DNS in this context.
jonas’ralphm, indeed
ralphmBut following the RFC on SRV records seems sensible.
moparisthebestI 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
Zashralphm: So does that mean the "fetch both _xmpp and _xmpps SRV and merge the results" is undesirable?
ralphmYes
ZashI tend to agree
moparisthebestthat 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.
moparisthebestyou have no guarantees that the SRV record came from the domain owner though
moparisthebestunless 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.
moparisthebestand 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.
moparisthebestbecause 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)
moparisthebestor 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
ZashDon't worry, be happy. Make sure you validate the TLS certificate.
moparisthebestif 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
moparisthebestSRV RFC is more generic, it doesn't know we have a foolproof way of validating the port we connect to by guessing
Zashvalidating ... by guessing
moparisthebestwe guess the port
Nekithas left
jonas’what?
moparisthebestwe 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
moparisthebestright, and that's fine
jonas’no it’s not
Zash400 WHAT ARE THESE ANGLE BRACKETS
Connection: gtfo
ZashI still think guessing is stupid
jonas’guessing is stupid and dangerous
moparisthebestit absolutely is, again running a public port on the internet means you are willing to accept whatever garbage anyone throws at you
moparisthebestand 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
moparisthebestthe 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
moparisthebestso 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
moparisthebestagain without DNSSEC you can't know that, you can only guess
jonas’okay, the discussion has just become a pointless loop
moparisthebestbottom 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
moparisthebestif 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
moparisthebestyou open a public port on the internet you have to be willing to accept anything anyhow at any time, period
Nekithas joined
jjrhhas joined
Zashso we have the two classic camps "fail early and hard on errors" and "just make it work at an ycost"
ZashXML vs HTML
Zashetc
moparisthebestI dislike being compared to HTML but otherwise sure :D
Nekithas left
goffihas left
igoosehas joined
ralphmIf you want to prevent connections, you can publish an SRV record with . as target
ZashAsk Ge0rG how common it still is for devices to not support SRV resolution
ralphmWell, if that's true, they are not able to have functional compliant XMPP implementations.
ZashI imagine the fault would most likely be in DNS resolvers in cheap routers or something
larmahas left
HolgerOr Tor.
ralphmBut wait, how does that prevent a client device from doing SRV? Or do you mean routers blocking SRV requests?
ZashBlocking or otherwise failing for unknown reasons
moparisthebestbecause a client generally gets their DNS server from DHCP which tells it to use crap router
HolgerWiFi routers having a built-in caching DNS server that's borked.
ralphmWell, 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
ZashAnd fallback combined with SRV not being critical for the web or email means nobody notices or fixes them.
moparisthebestof course DoX fixes this if you have a hard-coded ip+port for your resolver :D
HolgerOn 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
ZashHolger: Sounds like what Ge0rG has said about yax.im
ralphmHolger: wow. Are those corporate users?
ralphmAlso, how can you tell.
Holgerralphm: I don't think so; as I said, from what I've seen it's mostly crap end-user routers and Tor.
ralphmTor is not on my radar
ralphmBut how can you tell that users cannot use SRV?
Holgerralphm: I just check the percentage of the connections that are redirected from the A/AAAA target.
ralphmOh, you publish a different host in SRV?
Holgerralphm: Yes.
ralphmI kinda want users to complain to their ISPs.
Holgerralphm: Not sure about the Tor/crap-router ratio. But it's definitely not just Tor.
karoshihas left
Holgerralphm: 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.)
HolgerA popular thing in France was/is affected, for example.
moparisthebestalso 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
moparisthebestand 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
ralphmHolger: in most cases people get routers from their ISP. If not, they have themselves to blame for broken behavior.
waqashas joined
HolgerTrue that.
HolgerOf course neither will stop them from concluding what moparisthebest said. XMPP fails, everything else just works.
ZashCan't have nice things
ralphmAnd corporate users, well, should complain to corporate IT. There's no end to stupidity in that area.
ZashENTERPRISE
moparisthebest> Star Trek Fan Accidentally Accepts Job Writing "Enterprise Software"
ralphmWhen we worked on Jingle/WebRTC we had some issues with blocked UDP traffic in our office.
moparisthebestralphm, don't worry QUIC should fix that for you in a bit :)
ralphmThus wasting valuable bandwidth for calls between two people in the office.
ralphmmoparisthebest: I think QUIC has a lot going for it, but no.
moparisthebestZash, I think it's more like "can only have nice things if HTTP wants them first" :D
Zash:(
ralphmmoparisthebest: not in this case, I mean. I definitely would like to see XMPP-over-QUIC.
neshtaxmpphas left
wojtekhas joined
ralphmAnd indeed if QUIC would work in the corporate environment, then calls would too, since you can use the same port for TURN/STUN.
moparisthebestI 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
ralphmI think websites will fallback to plain http for a long time
rionQUIC+WebRTC ? I though wg abandoned this idea because all the id remapping crap for compatibility with STUN and absence of signalling ideas.
rionthought*
ralphmSure, but I believe even without changes, it can still be done.
ralphmEspecially with XMPP, as hey, we have signaling.
ralphmThe conflict is with TURN mostly
wojtekhas left
eevvoorhas left
frainzhas left
frainzhas joined
ralphmI 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
ralphmBut 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
rionIf web browsers could use our signaling out of the box that would be quite interesting.
ralphmHah, well! If I'm right, the webrtc library has roots in libjingle.
ralphmOf course with all the XMPP now removed.
Zashralphm: I have heard that as well
ralphmMaybe we could say XMPP caused WebRTC to happen.
neshtaxmpphas joined
igoosehas joined
UsLhas left
frainzhas left
frainzhas joined
Lancehas joined
frainzhas left
frainzhas joined
tomShouldn't IPv6 fix these issues as well?
frainzhas left
tombecause with IPv6, if setup properly every computer on then network get's it's own unique publicly routable IPv6 address
tomsometimes every device gets a whole range to itself
jonas’> because with IPv6, if setup properly
jonas’that’s the catch ;)
tomwell
jonas’but yes, IPv6 will (hopefully) make mayn things easier
jonas’but yes, IPv6 will (hopefully) make many things easier
tommost corporate enviroments are going to setup PFsense or OpenWRT
tomwhich sets up most of ipv6 for you ounce you give it an upstream
frainzhas joined
igoosehas left
tomwe aren't in the dark ages of proprietary router firmware ruling majority anymore, least not for professional space
tomtoo 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
ralphmI think your view on the activities or competence of corporate IT departments is extremely optimistic.
tommaybe that's just my area
ZashPFsense? OpenWRT? NOT ENOUGH ENTERPRISE
frainzhas left
tomthe 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
tomlike routing 400+gbps
tomwhere we'd use a switch fabric backplane
tomotherwise everything in the office areas flowed threw a PFsense box.
tomthe 1U unit they sell
ralphmYou might have been lucky.
frainzhas joined
Sevehas joined
ralphmI've seen IT departments being understaffed, underfunded, outsourced, and misused for setting up teleconferences.
goffihas joined
frainzhas left
frainzhas joined
Yagizahas left
moparisthebesttom, can you tell my corporate IT dept, they use all the proprietary blackboxes, riverbed, telari, cisco, and palo alto
moparisthebestand 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 :)
ralphmDude. I want to sleep.
waqashas left
Ge0rGpep.: I'm going to write that to standards in the context of reactions
XSF Discussion - 2019-07-18