XSF Discussion - 2018-01-10

moparisthebest, your post with Comcast on the SRV issue was written amusingly, brightened up my day :) ✏

Why do we have `&xep0077;` and `<cite>XEP-0077</cite>` na neitiher works as expected (show the full name on first occurence and just a hyperlink on any later one)?

Ge0rG: I always use &xep77; on the first time. But I agree it would be better if it only displayed the full name once

Probably not easy

daniel: computers were created to automate this sort of thing.

If you can make the xslt do that, I'm sure people will be grateful.

I can't. And I'm not sure I want to learn how to.

If I was immediately able to do it, I'd just implement it straight away and PR.

Exactly :)

jonasw: you are our in-house XSLT expert with some free time available, now that your exam is over.

will probably be tricky with XSLT 1.x

I use `&xep0077;` in MIX

I tried <cite> once and it was badly broken

So every XEP reference turns into the full text?

I don't think this is so bad. Someone fixed up the much more problematic issue of duplicates in the reference list, which was a big win (thanks to whoever sorted it)

It would also be good to be able to link to specific sections of an XEP

poor Jonas :)

Ge0rG, If I understand the RFC correctly, the authority component is used to "select" an account. So xmpp://foo@bar.com/juliet@example.com?roster would mean "add juliet@example.com to my roster of account foo@bar.com". Which is why the authority component needs to be a full JID

marc: Yes, this is a valid reading of the RFC.

Ge0rG, Good. Which is why xmpp://xxx?register doesn't make sense

marc: but what message would xmpp://juliet@example.com/romeo@example.com?register convey?

Well this doesn't make sense IMO because you can not register an account for a given account

marc: I would argue that xmpp://juliet@example.com?register would make sense, though, in the sense that you should register the account specified.

marc: That's not a full JID. That's a bare JID.

Kev, yes, I know :-/

Ge0rG, Yes, but look at the "?register" definition. I think they used xmpp:foo@bar?register on purpose and not xmpp://foo@bar?register

Ge0rG, However, we agreed that we don't need the inviter JID because it can be faked

I imagined it would be less text, but somehow it ended up rather complex: https://op-co.de/tmp/user-invite.html

is this ready for protoxep submission?

jonasw: not yet

what’s missing?

jonasw: there is a dozen of TODOs inside

we’ve got accepted XEPs which have that too

(bind2 I think)

(or had)

TODOs aren't a problem, I think.

(Sometimes even TODOs that make it unimplementable, depending on the circumstances)

I don't feel finished yet.

Besides, we won't get it into today's council anyway, will we?

Could if it's urgent I suppose, but not otherwise.

I don't think it is. Adding urgency won't make more people contribute to the public discussion.

It's also still self-contradicting in some places.

TODOs are a lot less of a problem than unsubmitted XEPs.

Hey Dave! I've been reading your proto-XEPs, and I have a feeling that CLIENT-KEY counters will get desynced and invalidated if a network outage happens during the handshake.

But I haven't completely understood the flow and conditions, so I might err.

jonasw: https://github.com/xsf/xeps/pull/568 (cc marc)

\o/

:)

Ge0rG, You're right. Various things in when, exactly, the counter is incremented could be improved. There are security issues tied in with all of them, though, I think.

Dave Cridland: yeah. My question is, how much thought you have put into the exact order of increments, and what the rationale is beyond what's written down.

Ge0rG, But we do assume that if the counter is desynchronized, the legitimate user can always use a password (and TOTP device) anyway.

Dave Cridland: that assumption is technically as valid as "the user can TOTP authenticate every single time"

Ge0rG, Right. But if you incrememnt the counter only on success, then it's susceptible to a replay attack, I think.

Dave Cridland: I've experienced many situations where my mobile connection changed multiple times in a row, providing just enough time to the client to begin authentication.

Dave Cridland: a replay of what exactly?

Ge0rG, The client-initial-response, specifically.

Ge0rG, Also, the counter has to be incremented at the same time at both ends. I think we run into a Two Generals problem if we try and make that perfect.

Dave Cridland: maybe all we need is some kind of transactional consistency? I'm not sure, I'd just like to rule out that the whole effect is ruined every other day

Dave Cridland, found a typo in the rfc draft (section 6.2): multiple values for Counter, increasingly the likelyhood of discovering a match.

*increasingly*

Dave Cridland, ha, I was about to say that with the Two Generals :)

jonasw, Ah, yes. Should be "increasingly the likelyhoodly of discoveringly a match" of course.

Dave Cridland, can’t you solve the replay issue (I haven’t dug deep into the draft yet) the same way SCRAM does, with a nonce?

specifically, is the counter only used to prevent replays without knowledge of the secrets involved?

jonasw, Well, sort of. So yes, but then you'd have to have the server store previous nonces, and ensure they weren't reused. Which feels, well, rubbish.

do we really need that, or can’t we say that 128bit of random nonce shall be enough for everyone?

jonasw, Ah, so no. A counter is used because it's predictably changing state.

I don’t see the purpose of the counter quite yet

jonasw, We could also use NotACounter = H(NotACounter) each time.

sure

in SCRAM, the nonce is composed of two parts (one from the server and one from the client), wouldn’t that work?

jonasw, But the idea is that where we see a correct ValidatorKey but an invalid resultant HMAC, we can make a reasonable assumption that the key has been compromised. THough as Ge0rG points out, this also occurs in some network failures.

marc, please see https://github.com/xsf/xeps/pull/568#issuecomment-356583982

jonasw, Yes, but it would introduce an additional RTT. The right channel binding data would solve this (and we do use this as well), but too many operating systems don't allow clients to get at that.

mh

jonasw, is there a way to sign it without registering on GitHub?

marc, I was expecting that. Kev ^?

jonasw, I can send you a handwritten letter for example

No clue, I wasn't involved in setting up the CLA stuff.

marc, I think we handled that via email before the CLAbot thing was invented.

I have no idea where the email went normally though, I need to figure that out.

I’ll just do what SamWhited did to me back then.

Getting someone to email in the agreement seems sufficient to me.

marc, I sent you an email, please reply keeping the CC intact.

jonasw, just replying a "+1"? :)

if you want to be super safe, copy the IPR policy into your reply; but +1 is essentially what I did.

jonasw, okay, thanks for the mail. I'll read the policy and reply then

moparisthebest, you said you don't know clueless admins, here is one: https://github.com/processone/ejabberd/issues/2214

I just read that Kontron [1] is implementing MQTT into its communication gateways (LoRa based). Do we have good showcases for using XMPP in a mobile IoT context? There's a lot of movement currently towareds standardized communication in public transport, but – if at all – I only see MQTT (or SOAP …) [1] https://www.kontron.de/

Kontron TRACe LoRa-MQTT https://www.kontron.de/products/systems/transportation-computers/trace-railway-computers/trace-lora-mqtt.html

just found that https://github.com/mgp25/Chat-API/wiki/FunXMPP-Protocol

is it just a dump version of https://xmpp.org/extensions/xep-0138.html ?

jonasw, Done

edhelas: yes, a custom compression scheme. they also had their own custom RC4 based encryption scheme and some custom authentication that was not very good. hopefully those are fixed by now.

but is it nocieably better than ZLIB ?

I mean this is just dictionnary compression, can work pretty well on XML

I wouldn't expect this to be better in terms of compression on longer sessions, as it doesn't even try to compress jids or body texts.

Which might be a good thing

Remember https://blog.thijsalkema.de/blog/2014/08/07/https-attacks-and-xmpp-2-crime-and-breach/

I member.

But it could easily keep a rolling dictionary of jids on both ends, and only send new jids in clear form.

It could also save on parsing time by adding information that would speed that up.

Before you know it, you're sending XMPP as ASN.1 ;)

That's sorta EXI, isn't it

Zash: it is.

zinid: no no I said admins that clueless should get another career, I stand by that statement hehe

My kid just picked out a new bicycle.

https://xmpp.igniterealtime.org:7483/httpfileupload/72bb37ec-a082-473c-9d00-e5a37eaa5b32/oTRaUDqyTneazojaH3P9og.jpg

close!

I swear I had nothing to do with it. 😁

Guus: I expect another picture where you've modded that Y to a J

now you must put a XMPP sticker on it

What Zash said.

Careful about modding it, those Cisco lawyers could be hiding anywhere!

You need to pay 500$ to the XSF, because it is obviously a piece of physical merchandise.

As long as the kid doesn't fancy becoming a courier it should be safe.

jonasw: is there another magic button you need to push for the proto-xep email to happen?

https://www.wired.com/story/whatsapp-security-flaws-encryption-group-chats/

edhelas: Shocking!

He who controls the server controls the universe!

that's why they added e2ee… wait

How is group membership enforced in OMEMO? Is the admin signing the participant key list? Oh, wait. Not defined at all.

:D

I think identity management is the weakest link in OMEMO.

Ge0rG, iirc everyone has to be on everyone's contact list

moparisthebest: that's a prerequisite to knowing their keys, except with omemo_for_all

or the omemo key nodes need to be public

moparisthebest: it's not a security guarantee of any kind, especially if you consider that the roster is owned by the server.

moparisthebest: so I should tell him "choose another career"?

Ge0rG, I *thought* the key had to be trusted too, but maybe not with BTBV not sure

zinid, yes 🙂

moparisthebest: so only friends can snoop on friends?

moparisthebest: very clever

Hi all. I'll be lurking here for a bit.

Hi Anu!

Hello, Anu!

Hi

welcome, Anu

if you lurk long enough, we'll ask you to do the dishes though.

hahah

Sorry, old irc habit. join a channel and watch a little before jumping in.

Anu, probably introduce yourself very quickly. i'm not sure everyone recognizes you by name. (I only figured that out myself because you contact me 1:1)

I was going to say that IRC is so 1999 - but that's probably not old enough :)

I still actively use IRC now :p

Anu, in general, a good habit I think :)

XMPP is 1999 ...

80's something?

I was talking on IRC during the gulf war..

Oh but apparently with IRCv3 they've got JSON and all the features

yea but it's like MIX

which one?

all spec'd out and no one in sight wants to implement it

I should properly introduce myself. I am Anu Pokharel, I develop Monal for iOS and OSX

1990 gulf war

good to have you hear, Anu (we'll still ask you to do the dishes, eventually)

Anu: actually it's awesome to have you here. Now we can complain even more about Monal ;-)

After the Board decides which dishes to wash first

complaints mean people use it i guess. :)

Anu: actually I have a hobby of installing XMPP software and flooding the developers with issue reports.

:'(

Anu: Ge0rG isn't joking.

Oh i know, Ive seen the bugs that hes sent me

;)

if it wasn't for Ge0rG and Link Mauve no XMPP software would have any issues

at least, reported issues

It's great. I've come to really appreciate people who test code for me.

https://github.com/anurodhp/Monal/issues?utf8=%E2%9C%93&q=is%3Aissue+author%3Age0rg - way too few, if compared with prosody or poezio.

But on the other hand, I'm not actively using the iPhone, it's just a dev device.

at least Anu is safe, Link Mauve has no apple device

I'm halfway through porting all the iOS code to a mac UI.

I hope to get more bugs then

Anu, screenshots of your App would be nice

Anu: in Monal/iOS I see many of my offline contacts listed multiple times. Restarting the app fixes it though.

Anu: also, do you have a beta channel / testflight?

Ge0rG, yeah its a bug in one my sql queries. Yes, I do send me your apple id. I need more people testing the next update prior to release

Also, please file a bug for that if there isnt already one so i can make sure its fixed

marc, jonasw, good to see the XEP up :)

pep., you forgot to mention Ge0rG :)

I just hit the "merge" and "send" buttons

(and even screwed up the merge)

Ge0rG, ^

jonasw: squash & merge?

Ge0rG, nah, more like "first ask for IPR signature, then merge" :)

jonasw, actually I don't understand why you merged it into master right now

marc, why not?

jonasw, I try to keep my master branches clean

But it's in the inbox, no?

So this *is* clean.

The inbox holds protoXEPs submitted for approval, but not yet Experimental.

I'm talking about Git commit history

marc, I don't think there's any issue with pushing early to master, you commit history is never clean anyway

pep., my is :D

How many rebase and push force does that take you

I think I don't understand the question. There was a PR requesting this be merged to master, so Jonas did. Isn't that right?

marc, the only way to make the website update is to push to master

that might be the bit of info you’re lacking

jonasw, ah okay

plus yeah it doesn't apply here

Didn't think about the website

> Ge0rG: Anu: actually I have a hobby of installing XMPP software and flooding the developers with issue

I feel neglected.

(as I'm pretty sure mine has most bugs of all :P )

Guus, do you have an iOS device, want to test monal ?

Anu: sorry, android

(although I was referring to the lack of issue flood from Ge0rG)

Guus: sorry, my time is limited.

(test)

Damn, my iPhone won't get detected by my VirtualBox.

probably have to do USB passthrough or something?

Yes. But it doesn't work.

marc, Ge0rG, any reason why ad-hoc and not say <iq/>?

pep., ad-hoc allows use from clients which don’t support the protocol yet

Does many client support ad-hoc already?

sure

even pidgin(!) does

Do

gajim does, poezio does

Conversations? Dino

dunno about those

yaxim

but you can always implement a specific ad-hoc flow without implementing all of ad-hoc or a generic ad-hoc UI

so if there’s interest in this thing, I guess that wouldn’t be a blocker

conversations definitly no, dino I think not

pep.: yaxim doesn't. But I'd for sure add support for the user-invite command

jonasw, I'm not sure I get your point about clients not supporting the protocol yet

pep., if you invent a protocol based on non ad-hoc <iq/>s, *all* clients have to be updated to be able to use it.

pep., if you use ad-hoc, clients which already have ad-hoc support can use the protocol right away.

Well here all clients have to implement ad-hoc

first

no

pep.: your clients are bad then :P

If they want to use this

no

no?

they could always just implement handling for that specific command, without running a full-blown ad-hoc implementation

(which is simpler)

Which would be the same as handling this specific command via iqs?

exatcly

pep.: yes, except that now there are already clients that support this

so for a client not yet supporting ad-hoc, it doesn't matter. And for clients supporting ad-hoc, they get it for free

yupp

and that’s the beauty of it

Ok, I'm just trying to understand here. So we should start implementing everything via ad-hoc commands right

no

not everything makes sense as an ad-hoc command

MAM for example; the result wouldn’t be very useful for a user

(ad-hoc commands are only useful if the result doesn’t need to be interpreted by the client in any way, but only by the user)

roster wouldn’t make any sense either, a client needs proper support for a roster for it to be useful.

hmm

jonasw, there are the server admin commands XEP which can be singled out by the client

mathieuii, sure

a client can always additionally implement fancy additional support for a given Ad-Hoc Command

but the command has to work well even without specific support

yeah, sure

Will the ad-hoc command be versioned or something?

If now a client want to special-case it and the XEP gets updated, you now broke everything

pep., there are specific rules how unknown fields are treated in forms

And lost all the interest of using ad-hoc

if the XEP updates adhere to that, there should be no issues

k

(and a client could fallback to the default ad-hoc handling (if it has some))

that's a lot of ifs

sure

things are worse with IQs though

if you make an update to a raw IQ protocol, this is (usually) a namespace bump, breaking the flow for everyone

(until the next update)

yeah, but you don't end-up with UB

Or defined-but-if-if-if

pep.: XMPP is full of defined-but-if-if-if

yeah :/

pep., it’s fully defined

but in addition to the defined behaviour, you can also play safe and fall back to generic ad-hoc handling.

But it depends if X has support for Y and Z and

But gotcha

no, if you supported an earlier version (okay, here’s one "if": and *if* the people updating the XEP didn’t do something stupid), that’ll continue to work

jonasw: the Council should prevent them from doing stupid things

Yeah I think I would prefer to have it versioned and break cleanly with a major update if needed, instead of wanting to stay backward-compatible until the end of times

At costs

pep.: you can always introduce a different command name.

pep.: which is exactly like a namespace bump

invite2

Ge0rG, heh, yes, but that doesn’t always happen :)

small remark, there doesn't seem to be in 0050 anything that restrict command name usage. Server could be using a conflicting command name, knowing that ad-hoc commands are often used in non-specified environments as I understand it

Though it's the same remark for server admin commands

pep.: yes. namespacing commands is a thin

+g

marc: just stumbled upon https://xmpp.org/extensions/xep-0186.html#nt-idm138620103579920 > In accordance with Section 3.2.2.1 of XML Schema Part 2: Datatypes, the allowable lexical representations for the xs:boolean datatype are the strings "0" and "false" for the concept 'false' and the strings "1" and "true" for the concept 'true'; implementations MUST support both styles of lexical representation.

ew

why not T and F and Y and N also

I mean if you are going down that rabbit hole, might as well see how deep

moparisthebest: it's merely about whether ibr= should be `true`, `1` or `y`

I'm not keen on inventing new protocol, just making the xmpp: URI as short as possible

So, how does XEP-0153 work in a MUC? You send the vcard get IQ to the participant full JID, and it gets forwarded to the user full JID? Intercepted by the user's account?

To the user bare JID, intercepted by the MUC

MattJ: forwarded to the bare JID?

Yes

MUC service handles everything addressed to participant JIDs

Because sending the IQ get to the MUC bare JID won't work out very well

What "handling" means isn't greatly defined, but a sensible MUC service will handle vcard requests by proxying to the user's bare JID

is there a XEP for that?

nafaik

It's just an implementation thing

Isn't that what XEPs are made for?

The MUC service could return a service-specific vcard (e.g. you have a muc.xmpp.org profile)

and still be compliant

unless someone can prove me wrong :)

MattJ: thanks very much. That helped me better understand the problem space. I hope I was able to make a useful suggestion for pep-vcard-conversion now

Dave Cridland: is the issuer name "XMPP" in totp-2fa an example or a normative constant?

Ge0rG, what's the "problem" or why do you mention this?

> Because sending the IQ get to the MUC bare JID won't work out very well Why not? Isn't that where you disco#info to as well?