XSF Discussion - 2022-03-17

this is roughly going to be my proposal for either extending XEP-0156 or making a new XEP, it supports secure delegation without DNSSEC, pinning public keys, encrypted-client-hello, additional connection methods like QUIC etc, the advice would be to grab this host-meta file first and if any of these methods exist (or a flag or something) to never do SRV/POSH/etc, thoughts/feedback/hate welcome: https://github.com/moparisthebest/xmpp-proxy/blob/master/contrib/host-meta/xep-0156-proposed.json

moparisthebest: looks good! My initial comments would be: I think a TTL would be better than "expires" - most people will not be dynamically generating these as they are served, and a TTL allows more reasonable caching without additional work.

Also I'm unsure about allowing arbitrary ALPN strings here. I'd lean towards keeping those out of it and just making clear which of the standard strings should be used.

+1 for ttl

moparisthebest, do you plan on forking RFC6415 as well?

Because while these extensions could be added to XRD just fine by using different namespaces, JRD doesn’t define extensibility at all.

> thoughts/feedback/hate welcome I hate JSON. Also, can my OCD suggest changing "ips" to "addrs" or something? If that's not in some spec already

I hate JSON _and_ HTTPS and *especially* the movement towards everything being HTTPS and JSON

Zash, you could suggest putting this all in DNS instead, to which we can remind you that DNS is over HTTP these days ;)

Lesser of the evils, I guess? The alternative is no nice things, aiui

(Until dnssec becomes a thing)

I have DNSSEC. Your argument is invalid!

I also have a local recursive resolver, no HTTPS involved!!

Zash, you're just ahead of time, in 20 years everyone will hate it "I'd use Matrix just fine BUT WTF JSON?!".

That's the same as being 20 years behind? Dang time loops!

:)

_It's all happened before_

That's how IT works, no? "WTF STARTTLS?! Direct TLS on 5223 is the thing!"

All this has happened before. All of it will happen again, and again, and again

> Holger escribió: > That's how IT works, no? "WTF STARTTLS?! Direct TLS on 5223 is the thing!" I would like to laugh but I lack the knowledge 😅

Holger: Can't wait for "WTF TCP? Encrypted IP is the thing!"

Unfortunately I fear between here and there it'll be 20 layers of protocols

🙁

Yea, encrypted IP over json over http/4 over udp

and http/4 will be over http/3 over quic over tls 1.3 over tls 1.2 over udp over ....

It's all over

all the way down

emus: I think people used to hate on direct TLS before, just don't really recall why

Additional ports required? Routing is complicated?

can't wait for CJDNS over XMPP over DNS over HTTPS i guess

Additional ports or IPs required unless you implement SNI

SNI moves concepts around in the stack in an uncomfortable way

Ah, right, there once wasn't sni

And then ALPN makes it worse

In Prosody, this meant code that previously only needed to care about connections on ports now needs to know about application level concepts like virtualhosts

But then mobile became a thing and suddenly everyone needs to connect over port 443 because stupid furewalls

That's not mobile

Web?

Yes. Because of web. That's why we can't have nice things!

The full circle

And because corporate firewalls blocking everything else for silly reasons, and people wanting to evade their corporate policies.

So now the port number has moved into TLS, and became an array of strings handled by OpenSSL. How does _that_ make you feel?

so how about building community networks to answer some of these needs?

Ironically, certain state-level firewalls started blocking quic over 443 and _only_ 443

Zash, i was doing SSLH some time ago... i much prefer having that standardized than relying on weird parsing rules :D

If only we could have had a sane routable IPsec-ish thing.

though to be fair i i would much prefer a secure DNS (GNS maybe?) and/or crypto-secure routing (CJDNS/Tor)

southerntofu, the point is that sslh shouldn't be necessary

Nor hacky parsing rules

thanks to ALPN or thanks to overzealous firewalls disappearing?

I read your message as "I like ALPN because it makes multiplexing multiple protocols on a single port easier", but multiplexing is only a response to stupid firewalls

ah yes it just made my life easier i'm not saying it's a good solution, "community networks" sounds much saner to me that working around filtered networks :p

Zash's point is that the port number used to serve the purpose that ALPN now is

fair

and if we wanted to secure that, putting the security between IP and TCP would have magic't everything, but we can't because middleboxxen

Now we live in a world where we have wasted space in the IP packet because it will eventually be hard-coded to '443'

in the TCP*

IP doesn't have ports, only addreses

who needs 50k ports when you have many more IPv6 on every ISP-provided subnets? /s

YES, One IPv6 address per application!

Wouldn't it be better to always use just one hostname/IP, and to include what host and service you want in the TLS negotiation? You can do away with DNS completely that way, and we don't need to get DNSSEC universally deployed.

So you always just connect to https://8.8.8.8 and you're done.

isn't that what SNI is about?

Hello Cloudflare

Hello Matt

oh, we're not in the erlang movie? sorry.

> So now the port number has moved into TLS, and became an array of strings handled by OpenSSL. How does _that_ make you feel? It makes me sad... that I miss all the fun by not developing server software :p

mjk: it is never too late

I dipped my toe once, actually. Though the effort back then was spent not on multiplexing services on one addr:port but on figuring out why a sync filesystem operation in an async callback deadlocked my server 🙄

deadlocks are teh worst kind of locks

lol

doorlock? just pwn it in case of need. deadlock? you're screwed

i'd much rather drill through doorlocks than debug deadlocks thank you very much :D

true

the culprit turned out to be ~windows~ an alpha-quality library

aren't we all

(seriously though why are networked filesystems so bad? SFTP/SCP works fine but NFS/SSHFS using a desktop environment is teh worst when there's bad network conditions)

southerntofu, this probably comes from the Unix abstraction of files, which defaults to blocking reads.

...and doing filesystem in the ui thread

If the file system layer isn’t able to provide the data requested by the process, it will block the read() syscall.

soooo just try to get "random people" using network shares when it will freeze or otherwise hinder their file browsing experience

(last time i tried i learnt that it's perfectly reasonable for nautilus to become unresponsive even to SIGKILL when a networked file system has entered a weird state)

(i mean i find that curious but the non-technical user was (understandably) more than frustrated)

at least cifs driver has the option to error out instead of blocking on network problems :)

Yes, being blocked in a syscall means the process won’t ever get scheduled, and thus can’t react to signals.

and won't ever return to life even when the network interruption was just a few seconds... great state of things! /s :D

No, if the fs obtains the data, it should resume and finish the syscall.

that's a big "if" apparently...

southerntofu, the issue here is applications’ assumption that reading a file will finish in reasonable time, and thus can avoid async by using blocking syscalls.

"should" <-- yes and we should have peace and prosperity for all on this planet, but well..

southerntofu, if you encounter an issue in a driver, please file a bug against it.

Same for any other piece of software really. :)

i sure try! but i'm not always ready to spend hours trying to debug something, especially when it's not on my machine :P

and we all lived on topic ever after...

Oops, sorry!

my bad

or my, we'll never know!

let's go back to extremely straightforward federation or whatever XSF stands for ;)

thanks for the feedback all, let me see if I can address it: 1. MattJ, jonas’ , I agree expires is strange, I didn't add that though, that's in the RFC, seems reasonable to add an xmpp-specific TTL to be used instead though...1 2. MattJ , https-svc has arbitrary alpn strings... I agree it's a bit strange in the context of xmpp because we are already saying it's directtls or quic outside of that, hmmmmm 3. Link Mauve , I mean xep-0156 "extended" the json format without forking RFC6415, seems fine to me? 4. mjk , Zash , well the alternative is https-svc DNS records, except they can only be used for https so we'd have to fork our own that then would never get widespread deployment enough to use them and also lack of DNSSEC, fwiw this makes me sad too if I missed something please bring it up again...

moparisthebest, XEP-0156 as it currently is doesn’t extend the RFC, it just describes two @rel values to mean BOSH and WebSocket endpoints respectively.

Link Mauve, RFC6415 says these two things about JRD: > as extensibility is beyond the scope of this specification. > The conversion of any other element is left undefined. I don't interpret either one of those as "you can't add anything" do you?

moparisthebest, given JSON has no concept of namespaces, I would be extremely wary of conflicts here.

I don't think I care, why would anyone be trying to process a rel="..." it didn't understand ?

every json deserializer I've seen explicitly ignores unknown fields for this reason right?

Do they now?

serde_json does

fun fact, the XML in RFC6415 is actually invalid per the XSD, go ahead and try to validate it https://code.moparisthebest.com/moparisthebest/xmpp-proxy/src/branch/master/contrib/host-meta

(could use github.com instead but it's down right now LOL)

You should poke people to create an errata.

But isn't it more fun to leave it as it is?

it's like an easter egg!

If you find it, you win a prize!

I believe that Dave has encoded various invitations for drinks in XEPs.

That is a great rumor to spread

People might actually read them!

Meeting time, who's here?

Based in fact, I'm sure.

0. Welcome!

Who do we have

Here

For some reason you feel closer this week :D

Hi

Its 10:00 a.m. this week, so I am more awake

Nice

Any items for today?

Not that I'm aware of

The only thing that was raised to me was a message from emus about GSoC financials, but I don't think Board has to be involved and that he can do this directly with Peter.

o/

I agree

hey MattJ, you got anything?

I don't think so, no

Easy peasy.

(I mean, only covid... :) )

Ow. Be well, sir!

1. Date of Next

+1W

2. Close

Thanks all!

wfm, thanks!

As you were!

Hey so does daylight savings happen in Europe next week?

arc: I think so. Last Sunday in March afaik

. ✏

That should be clearly mentioned at the end of the meeting, if we're adjusting meeting time relative to UTC

moparisthebest: > if I missed something please bring it up again... The "ips" field! It lists IP addresses, not internet protocols! "addr(esse)s" plz :)

Google calendar says time remains the same for next week

mjk: ah sorry thanks, https-svc has these too but calls them "ip4hint" and "ip6hint" ...

Hmm

I always find "address" to be ambiguous - does it accept an IP address, hostname? or both?

We have a few of those "slots" in XEPs

> ralphm escribió: > The only thing that was raised to me was a message from emus about GSoC financials, but I don't think Board has to be involved and that he can do this directly with Peter. I was still not able to find a working contact. Thats a general issue with IDs in the wiki. foreigners seem to be blocked

arc: indeed, DST change in Europe is on March 27 this year.

Maybe someone can send him my a message and to contact me

I sent you his e-mail address

mjk, https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-08.html#section-7.4 sorry it's "ipv4hint" and "ipv6hint"

is there a reason to differentiate between v4 and v6 ? I'm wildly guessing they do in DNS because everything is binary and with a defined length, in json seems like you could just look at them

ralphm: thx

> in json seems like you could just look at them Yeah, the mixed bag seemed fine to me as is

MattJ: > I always find "address" to be ambiguous - does it accept an IP address, hostname? or both? To me, addresses, if referring to hostnames, are more of a user-facing term, whereas addresses at protocol level seem unambiguously referring to numeric things. But maybe just me ¯\_(ツ)_/¯

Anyway, "iphints" sounds more-or-less fine to me too :)

Https-svc calls them hints because you might look up the domain name otherwise later and I'm explicitly not supporting that

Here it's "you should connect directly to these IPs and nothing else"

Maybe "ipdemands" hehe

"ipaddrs" it is, and sorry for all the bikeshedding

"connectables"

make no one happy... :)

"endpoints", if we were to be deliberately ambiguous, but sound modern and jsony!

Say, mod_onions allows tor federation, but only for servers that enable it. Why not iterate that, and have a way to hop to a tor-enabled server and then on to the target?

Because: > Come to think of it (from talking to wgreenhouse about briar earlier), if you just package prosody with mod_onions, tor, and a client, you got a free p2p chat app

MattJ, Zash how does that check incoming s2s? is https://hg.prosody.im/prosody-modules/file/824b0d7fa883/mod_onions/mod_onions.lua#l268 called? if so it's wrong :/

qy, seamless secure federation between .onion servers and public net servers is an explicit near-future goal for xmpp-proxy, as well as documenting best practices for .onion federation which I don't think has been done before

Neat

both handling .onion JIDs and public servers with .onion endpoints in SRV or whatever, which... are subtely different

I've thought about writing an informational XEP about that a handful of times, but don't have enough experience with it. I'd love to see one written up.

I don't know about anyone else but I can never work out the fine details until I write the code, so that has to come first for me :P

I don't even know how this would theoretically work, but i'm sure it could

moparisthebest, I've been assured by multiple people in the past that it's not wrong. But I've never used nor worked on that module.

from what I've thought about so far, my plan is requiring all .onion domains to have a TLS certificate, *any* TLS certificate (ignore names, expiration date, everything), when connecting *to* one (as a client, or s2s-out), just accept it if you are connecting to a .onion the tricky part is s2s *in*, where you get handed a cert and told an .onion is connected to you, my proposal there is to make an *outgoing* connection to the .onion, and trust the certificate only if the incoming one is exactly the same as the one you got making the outgoing connection

Looks like it hasn't changed at all for years

MattJ, that's fine for outgoing, but is it ran for incoming?

incoming as in sasl external authentication

It would apply to both, unless there's a reason it doesn't

Not a helpful statement, I know

if so, that means anyone can connect to a prosody server with that loaded, present *any* certificate, claim to be from "bob.onion" and start spamming your users

That's how it would read, yes

you'd never get responses back I guess, unless you could trick it into bidi

Seems so, yes, unless there's some other check that the connection is coming from localhost

that sounds like an awesome spam tool :D

anyone have a public server with that loaded that wants to give me permission to poke at it ? :)

Hello, I just came by to say: You got it all wrong. Now back to watching comedy! Bye

> some other check that the connection is coming from localhost Wait no, that's stupid too. With all the nginxes and sslhes

well, good :)

> moparisthebest wrote: > from what I've thought about so far, my plan is requiring all .onion domains to have a TLS certificate, *any* TLS certificate (ignore names, expiration date, everything), when connecting *to* one (as a client, or s2s-out), just accept it if you are connecting to a .onion > the tricky part is s2s *in*, where you get handed a cert and told an .onion is connected to you, my proposal there is to make an *outgoing* connection to the .onion, and trust the certificate only if the incoming one is exactly the same as the one you got making the outgoing connection So really, just shifting from name-based routing to cryptokey routing

> Zash wrote: > Hello, I just came by to say: You got it all wrong. Now back to watching comedy! Bye Thanks fermat

qy, I mean it's still name-based, you just need TLS to validate incoming connections

.onion only provides authenticity when you are connecting *to* it

Right, yeah

If only Tor provided a virtual interface where incoming onion connections would be coming from something like 10.x.x.x, and the reverse lookup would yield the onion name...

Why specifically TLS, though? Any asymmetric key would do, a TLS tunnel is superfluous over tor

mjk: That is doable actually

TRANSPort

qy, "when you have a hammer everything looks like a nail"

qy: it is, just not the default conf

Lol

mjk, qy, tor doesn't even have a concept of "making an outgoing connection from a .onion domain" does it?

Not as i'm aware

Hmm right

another secure thing to do would be to do dialback over tor

but... who wants to do that

I feel like the already documented "same cert" hack is the best+easiest, and works with anything that provides outgoing-authenticity, onionv2, onvionv3, i2p, what else?

In my mind anyway, the hard part is clearnet->onion routing. A fresh prosody knows nothing about remote servers that can marshall over to tor, until an incoming connection _from_ tor

So without mod_onions you can't make that iteration

Was this for onion->onion S2S connections? I wonder if you could just use onion service client authorization and tell the XMPP server to use the same keypair as the service. You'd then validate that they match the descriptor of the onion service when you connect to it (or if you've already connected to it and it's dialing you back), no TLS certs involved?

near-term xmpp-proxy will have a config box for you to put the socks5 server+port of your local tor daemon

future xmpp-proxy will (optionally) bundle tor's new rust library and just handle it itself

tor is being rewritten in rust with the explicit goal of being an easily embeddable library, it just isn't there yet

Well that would simplify a lot, just shove tor into prosody :p

"problem solved" :)

_dusts hands_

Are there Rust libraries for generating Lua bindings? :3

all bindings are C, you can generate C libraries from Rust, and use them from Lua

mjk, yes, see the mlua crate for instance.

Can't rust expose 'extern "C"' functions?

yes that's what I mean

Aha

Then I'm content

(So FTR: `return true` just means "validation has completed", but it doesn't record the certificate validation results, so they stay unknown and it'll probably go do Dialback)

mlua is more pleasant to use than the C Lua API though.

Zash, ah right!, no session.secure = true, thanks!

so prosody mod_onions requires dialback then

Rather it's _not_ setting the certificate chain and identity validation properties like https://hg.prosody.im/trunk/file/0.12.0/plugins/mod_s2s_auth_certs.lua

> mlua is more pleasant to use than the C Lua API though. Anything is more pleasant than keeping half the stack in your head..

Pushed a comment to mod_onions, thanks Zash

I know this isn't the first time you've explained it, but hopefully now it can be the last ;)

haha thanks :) mini heart attack averted

A new post on GSoC to promote our ideas again: https://fosstodon.org/@xmpp/107974022090404224 https://twitter.com/xmpp/status/1504571740650934283