XSF Discussion - 2018-05-02

in a xep xml, is there a way to do this:

Reference: [&xep0368;]

for a protoxep ?

like a 'this xep'

moparisthebest, just write "this xep"?

😆

moparisthebest, I’ve seen your draft -- are you on a mission to make Zash incredibly sad?

moar context pls?

flow, https://github.com/moparisthebest/xeps/commit/364a577a30e1d42d6fb169e596921befc2c16873

quite a dance for an xmpp connectiono

So this is like POSH but with added connection infos

though what is the use case

?

is there a use case where we cant put these infos into srv entrys?

lovetox, not sure if one can resolve SRV from within a web client

https://www.w3.org/TR/raw-sockets/

moparisthebest, I'm going to need a crapload of reasons why this proposal isn't duplicating DOH etc.

DOH?

Because nobody supports DNS over http🙄

I see your point though

moparisthebest, have you seen https://xmpp.org/extensions/xep-0156.html#http ?

jonasw: for discovering domain name and port an extension to XEP 0156 would be IMHO sufficient, but as far as I can see moparisthebest wants something that could contain info about SNI/ALPN to be used as well as public key pins, etc.

uh

that doesn’t make sense to me

but I bet there’s a rationale

especially that public key pinning is being withdrawn from browsers...

Well, yeah. The problem with HPKP *in the browser*, is that if at a point in time, the wrong header was received by the browser, there is no way to undo this, except for waiting until that header's expiry. Besides the actual owner of the website messing up, the other issue is with somebody hijacking your website in some way, if only temporary, and issuing cripling headers.

Of course, for mobile apps, this is different. There, you still have the option to issue a new version of your app.

apps should just do cert pinning

ralphm: yes, but the xeo that moparisthebest is authoring would be more similar to hpkp in the browser (as I guess xmpp clients would not ship with this list and would not update the list as servers change their pins)

Ge0rG: please explain how you handle cert expiry. Unless you meant public key pinning, in which case I will ask: how do you handle revocation in case your secret key is compromised?

Ge0rG: cert pinning can be more dangerous than key pinning, in case someone revokes your cert you're out of options, see https://scotthelme.co.uk/the-power-to-revoke-lies-with-the-ca/

Wiktor: I think HPKP definitely has merit, so if you can mitigate the above by having some way to recover from faulty headers, yay!

ralphm: indeed I'm using "cert pinning" as a loosely defined term for pinning either the SPKI, the certificate or the CA cert.

ralphm: which of those should be taken, I'd decide on a case-by-case basis

ralphm: well, it's just a very sharp blade, if you take extra care then sure, but I wouldn't recommend it lightly

ralphm: I think it's not too far-fetched to have a long-living self-signed cert for an app and to roll out a new app version in case of compromise.

Ge0rG: new app version? that'd tightly couple client to server, for centralized service such as Signal this is OK but for XMPP all clients would need to be upgraded... unless I'm missing something in this design :)

I agree that rolling out a new app is the easier way, but using HPKP in this particular case makes it more seamless to the user. Having to tell your user to upgrade, is a) painful, b) not trivial if you depended on the certificate/key to deliver a notice to the app.

Wiktor: I'm only talking of apps that are bound to a given service. For other (xmpp-style) apps, I've written https://github.com/ge0rg/MemorizingTrustManager

ralphm: right. with sufficient planning, you can have a fallback pin in the app, too ;)

got it

Ge0rG, I’d have a backup cert in a secure store which the app already trusts. if cert A is comprimised, I roll out cert B on the services. App would distrust cert A once it has seen cert B in the wild.

then I’ve got some time to roll out an update with cert B as primary and a new cert C as backup.

jonasw: that is more or less exactly HPKP

There is an easy solution: don't lose your private keys :P

Ge0rG: thanks for your theoretical insight

ralphm: I'm full of those. Ask me for more any time

Ge0rG, ah, damn, so simple a plan! pity that *I* didn’t think of that. Maybe make that an RFC, it’s genious :)

:facepalm:

I wonder whether we want a way to signal in-band that an account has been deleted.

example use-case: user A registers at foreign biboumi instance B, joins a channel and sets it to persistent. account of user A gets deleted. biboumi will forever be in that channel for no use

idea: send <presence type="unavailable"><deleted/></presence> in response to presence probes.

type="error" <gone/>

Already in the RFC

MattJ, oh

did I say something?

But biboumi won't actively contact the JID and hence not receive that stanza error, right?

Oh "in response to presence probes". biboumi generates presence probes?

Should servers send out that to bookmarked rooms or something?

Would sorta fit with the move towards account based groupchats

Holger, yeah, biboumi would have to poll or do something similar

That could also help affiliation list entries and nickname registrations and stuff like that.

(or require presence subscription)

Dave Cridland, DOH is only provided by a few providers and is easily blocked, plus SRV records can't contain sni/alpn info

the entire point of this is to be censorship resistant, I haven't gotten down to use cases and such yet

it also supports domain fronting and such

Use Tor?

I hear china is pretty good at blocking tor

I don’t think this makes a lot of sense in general use-cases.

china is pretty good at blocking a lot of stuff, even if running via VPN.

You can't crypto your way out of *blocking*

you can to a point

And is blocking equal to censorship?

yes? it's designed to get around blocking

and application code should be able to use the exact same logic as for xep-0368 (and kinda-posh) except a single https call instead of DNS queries

it's a total hack that shouldn't exist, you can thank oppressive regimes

I don't follow why this is more resistent than DOH etc.

Dave Cridland, because each xmpp server runs their own

it's federated

So you just block the XMPP server IP as a whole?

then the operator spins up another xmpp server someplace else

Calling everything censorship annoys me. :(

also you can use tricks to make it not look like an XMPP server

(you could inspect IP + User-Agent requesting this document and lie to russian govt with a 404)

plus it supports domain fronting (send sni someunrelatedservice.com) and nothing else currently does

Chinese VPN detection is based on traffic patterns, so even if you tunnel through https, they'll throttle you into oblivion

xmpp runs pretty well on slow connections doesn't it?

Sure

It can do. I'm not entirely certain how many standard implementations handle it

e.g. I think some clients aggressively ping the server

oh thought of another reason for this, telegram is handing different server blocks to different people based on region to make IP blocking harder

and you can only do that if you can afford to run your own DNS network

unless it's just a page on a web server in which case any tiny xmpp server can do it

how many IP blocks does a tiny xmpp server have, typically?

hah

0

something between 0 and 1 I guess

as long as you don't take in account ipv6

Maranda: how many non-consecutive IPv6 blocks do you have?

ipv4 I got like 3 IPs, ipv6 one native, and one /48 tunneled.

Maranda: 3 IPs from different ISPs?

(on the xmpp server vps, but it does different stuff)

Nay?

Maranda: how do you want to get around blocking with that?

well they're non consecutive though

"how many blocks with different rwhois do you have?" is probably the most reasonable question in this context ;-)

the ipv4 addresses are all from different CIDRs

I've got a dozen or so IPs from my core ISP, over two different CIDRs. And I could arrange for traffic redirects on two other ASNs, more if I involve friends.

Ge0rG, I'm not sure neither I care about blocking I just answered your ip question btw

Ge0rG, well if you could aws and such, a lot

moparisthebest: do the moxie dance?

regardless, way more than if you have to run your own distributed global dns network

Ge0rG, that's the whole point yes

I don’t see use in that, to be honest

it will be way too complex for any server or client to implement *with actual benefit*

jonasw, anything that implements 368 and http upload should be able to implement this with, ~20 lines of code max?

moparisthebest, but there’s no benefit

as Ge0rG said, you need quite a bit of resources (both time and money) to do the things which bring the benefit here

jonasw, the benefit is evading blocks

I am aware

you can't evade blocks if all you have is one IP address.

yeah

you can if they don't know it's an xmpp server, and you can for a bit

then you jump to a different xmpp server

yeah, but, who has the time resources to actually do that

plus right now even big xmpp servers can't do domain fronting etc without custom clients

this would enable that too

well I added on lightwitch.org a xep 368 record for direct tls c2s on port 443, I played with port multiplexing a bit.

:P

yeah, 368 was simple and such, which is why it gained adoption really fast

and noticed Conversation is actually using it.

but this isn’t simple

explain how it's any different?

and it doesn’t bring any benefit without additional resources (time to hop IPs, and the actual IPs to hop to)

jonasw, I'm not sure if I should consider implementing direct tls for s2s too...

jonasw, it does, domain fronting

moparisthebest, where does that still work?

I heard google and AWS kill you if you do that

if you are a huge service like signal maybe

just as a future view, this is step 1 to censorship (blocking for Zash) proof xmpp

other stuff we talked about is being able to keep your contact list/conversations and hop between any xmpp server you like at any time, even being able to be connected to multiple at the same time (clients would ignore jid and use a cryptographic identifier instead, servers would be unchanged)

fun stuff

oh also allowing contact's clients to route messages, the fun possibilities are endless

that’s mostly stuff you talked about, which I personally find quite unneeded and overkill

before venturing in that direction XMPP should get it’s basic sh*t together.

we’re still losing messages (#thanksomemo)

sure if you don't live in a place that is blocking secure chat apps this is entirely un-needed jonasw

moparisthebest, a place which is blocking secure chat apps will block XMPP too when the time has come

Yeah, can we get all our shit, put it in backpack, so it's together.

not if we make it impossible to block with those changes?

that is after all the entire point

that won’t make it impossible.

only harder

you only have to make it hard enough so it's not worth trying

moparisthebest: https://www.schneier.com/books/secrets_and_lies/pref.html this was a good read

it looks like https, anyone can use any server, so as fast as you block them, new ones pop up and you interrupt no one

I think you need to read it

moparisthebest, it does not look like HTTPS

it may look like HTTPS on the byte level

but the chinese are very godo at blocking based on patterns

you won’t stop /that/ with your fancy stuff

(with patterns, I mean packet sizes and timings)

so it looks like any modern interactive html5 app?

moparisthebest, not quite

take a look at their research.

they can detect e.g. Facebook quite certainly even through a VPN.

> being able to keep your contact list/conversations and hop between any xmpp server you like at any time, even being able to be connected to multiple at the same time (clients would ignore jid and use a cryptographic identifier instead, servers would be unchanged) Haha, sure. We fail at fixing avatars.

Zash, I read this one https://www.schneier.com/books/data_and_goliath/

my thoughts exactly, Holger

that's just client-side changes though, you could make a version of conversations that did that today without anything extra required from servers

it would even be backwards compatible with other clients, though not very friendly UI wise in them

"just clients"

because clients aren’t the main problem :)

you specifically mentioned avatars which require all clients and all servers to change

you'd agree changing a single client is easier right?

Well if we're just interested in a single client then the avatar issues become much easier to solve as well.

Whatever. Just implement it if it's so simple?

I plan to

+1

I don't really write specs without implementations

usually the implementations come first, I think that makes me a bad programmer, oh well :)

I think you wanna write specs and implement at roughly the same time

+1

Maybe think real hard about requirements first.

But all that goes out the window when you start implement anyways

I don't think I've ever seen a pre-written spec survive an implementation unscathed

> clients would ignore jid and use a cryptographic identifier instead Congratulations, you just combined the drawbacks of XMPP with the drawbacks of p2p systems and the drawbacks of mixnets

I looked at it the other way, benefits if p2p systems plus benefits of XMPP

moparisthebest: what's the benefit of XMPP once you replace JID-based routing with crypto identifiers?

Why not XEP-0174 over .onion nodes?

Why not normal xmpp over .onion?

Ge0rG, routing is still jid-based, clients just collapse multiple JIDs using the same crypto identifier under one 'contact'

and the benefit is still all the other things xmpp provides, one of the biggest being it's mobile-battery-friendly

moparisthebest: how do you tell your buddies about your new JID if they also just switched JIDs because of blocking?

I don’t even want to think how that works with MAM queries

or MUCs.

or anything non-trivial really

moparisthebest: you just invented a crypto-overlay network over XMPP.

right that's exactly what it will be

moparisthebest: but WHY?

fun and censorship resistance? :P

for certain definitions of fun

not to kinkshame, but I’m not into that I think

moparisthebest: it won't get you censorship resistance.

moparisthebest: because once your server is censored, you have no way to find out the new identity of your friends

I guess that is a problem if you both switch at the same time

DHT over XMPP ?

why use xmpp if you can have QUANTUM BLOCKCHAIN TECHNOLOGY!

https://wiki.xmpp.org/web/Secure_Distributed_JID_Discovery

in particular https://wiki.xmpp.org/web/Secure_Distributed_JID_Discovery#DHT_Based_Solution

nice

verification would be solved since the identifier is a cryptographic key anyway

Discussion at https://mail.jabber.org/pipermail/standards/2013-February/027036.html

Open Problems: 1. How to prevent impersonating other users.

solved by crypto already

moparisthebest: Zooko called, and he wants his triangle back.

that's a problem *there* because you want to prove a certain jid has a certain phone number

my thing would only want to prove a certain jid has control of a certain cryptographic key, which of course is super easy to prove

for certain values of "super easy"

moparisthebest: my point is: the XMPP model is not suited for what you want.

I don't know why you'd invent something else to give you everything XMPP does when you can just overlay it?

moparisthebest: because you'll end up with a system that combines the drawbacks of xmpp with... we've been here already.

I'm on both sides :)

If you're going to make such a system, using XMPP as a foundation buys you a lot

It would of course be quite different to what we have today, I don't think sane interop can be expected

I want to see a list of reasons, not some hand-waving of how great xmpp is.

Okay, thanks. That's a reasonable response.

<-- fixing production issues

okay let's see if direct tls for s2s causes a meltdown...

is there any s2s implementation of it?

jonasw, I think zinid said latest ejabberd supports it

plus metre

Oh Metre does it?

tested it with ejabberd

let's see Metre

Isn't metronome a prosody fork? How hard would it be to patch prosody the same way Maranda ?

I'm not entirely sure, my knowledge of Prosody's codebase sort of stilled at around 0.9 tbh 🤣

But I suppose "not much"

Do you support SNI and alpn too ? (For outgoing connections?)

nay

Not even SNI? That's a must

moparisthebest, nai and luasec 0.5/0.6 which are the most common around don't support SNI anyways

moparisthebest: No need, the unencrypted stream header has it.

2005 called and wants it's TLS extensions implemented

LuaSec has had SNI a long time FWIW

at least I'm sure LuaSec 0.5 doesn't support it

Just make sure you fall back on cert errors

nope doesn't