XSF Discussion - 2022-03-17


  1. moparisthebest

    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

  2. MattJ

    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.

  3. MattJ

    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.

  4. jonas’

    +1 for ttl

  5. Link Mauve

    moparisthebest, do you plan on forking RFC6415 as well?

  6. Link Mauve

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

  7. mjk

    > 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

  8. Zash

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

  9. MattJ

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

  10. mjk

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

  11. mjk

    (Until dnssec becomes a thing)

  12. Zash

    I have DNSSEC. Your argument is invalid!

  13. Zash

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

  14. Holger

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

  15. Zash

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

  16. mjk

    :)

  17. mjk

    _It's all happened before_

  18. Holger

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

  19. Zash

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

  20. emus

    > 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 😅

  21. Zash

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

  22. Zash

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

  23. emus

    🙁

  24. mjk

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

  25. Zash

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

  26. mjk

    It's all over

  27. mjk

    all the way down

  28. mjk

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

  29. mjk

    Additional ports required? Routing is complicated?

  30. southerntofu

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

  31. Zash

    Additional ports or IPs required unless you implement SNI

  32. Zash

    SNI moves concepts around in the stack in an uncomfortable way

  33. mjk

    Ah, right, there once wasn't sni

  34. Zash

    And then ALPN makes it worse

  35. Zash

    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

  36. mjk

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

  37. Zash

    That's not mobile

  38. mjk

    Web?

  39. Zash

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

  40. mjk

    The full circle

  41. Zash

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

  42. Zash

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

  43. southerntofu

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

  44. mjk

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

  45. southerntofu

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

  46. Zash

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

  47. southerntofu

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

  48. MattJ

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

  49. MattJ

    Nor hacky parsing rules

  50. southerntofu

    thanks to ALPN or thanks to overzealous firewalls disappearing?

  51. MattJ

    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

  52. southerntofu

    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

  53. MattJ

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

  54. southerntofu

    fair

  55. Zash

    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

  56. MattJ

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

  57. Zash

    in the TCP*

  58. Zash

    IP doesn't have ports, only addreses

  59. southerntofu

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

  60. Zash

    YES, One IPv6 address per application!

  61. Kev

    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.

  62. Kev

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

  63. southerntofu

    isn't that what SNI is about?

  64. MattJ

    Hello Cloudflare

  65. jonas’

    Hello Matt

  66. jonas’

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

  67. mjk

    > 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

  68. mathieui

    mjk: it is never too late

  69. mjk

    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 🙄

  70. southerntofu

    deadlocks are teh worst kind of locks

  71. mjk

    lol

  72. southerntofu

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

  73. southerntofu

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

  74. mjk

    true

  75. mjk

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

  76. southerntofu always happy to point the finger at windows, trying to hide all those NFS/SSHFS deadlocks under the carpet

  77. mjk

    aren't we all

  78. southerntofu

    (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)

  79. Link Mauve

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

  80. mjk

    ...and doing filesystem in the ui thread

  81. Link Mauve

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

  82. southerntofu

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

  83. southerntofu

    (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)

  84. southerntofu

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

  85. mjk

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

  86. Link Mauve

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

  87. southerntofu

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

  88. Link Mauve

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

  89. southerntofu

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

  90. Link Mauve

    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.

  91. southerntofu

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

  92. Link Mauve

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

  93. Link Mauve

    Same for any other piece of software really. :)

  94. southerntofu

    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

  95. mjk

    and we all lived on topic ever after...

  96. Link Mauve

    Oops, sorry!

  97. southerntofu

    my bad

  98. mjk

    or my, we'll never know!

  99. southerntofu

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

  100. moparisthebest

    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...

  101. Link Mauve

    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.

  102. moparisthebest

    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?

  103. Link Mauve

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

  104. moparisthebest

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

  105. moparisthebest

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

  106. Link Mauve

    Do they now?

  107. moparisthebest

    serde_json does

  108. moparisthebest

    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

  109. moparisthebest

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

  110. Link Mauve

    You should poke people to create an errata.

  111. arc

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

  112. moparisthebest

    it's like an easter egg!

  113. arc

    If you find it, you win a prize!

  114. Guus

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

  115. arc

    That is a great rumor to spread

  116. arc

    People might actually read them!

  117. arc

    Meeting time, who's here?

  118. ralphm

    Based in fact, I'm sure.

  119. ralphm bangs gavel

  120. ralphm

    0. Welcome!

  121. ralphm

    Who do we have

  122. arc

    Here

  123. ralphm

    For some reason you feel closer this week :D

  124. jcbrand

    Hi

  125. arc

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

  126. ralphm

    Nice

  127. ralphm

    Any items for today?

  128. arc

    Not that I'm aware of

  129. ralphm

    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.

  130. MattJ

    o/

  131. arc

    I agree

  132. ralphm

    hey MattJ, you got anything?

  133. MattJ

    I don't think so, no

  134. ralphm

    Easy peasy.

  135. MattJ

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

  136. ralphm

    Ow. Be well, sir!

  137. ralphm

    1. Date of Next

  138. ralphm

    +1W

  139. ralphm

    2. Close

  140. ralphm

    Thanks all!

  141. MattJ

    wfm, thanks!

  142. ralphm bangs gavel

  143. ralphm

    As you were!

  144. arc

    Hey so does daylight savings happen in Europe next week?

  145. mjk

    > 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 t > if I missed something please bring it up again...

  146. Zash

    arc: I think so. Last Sunday in March afaik

  147. mjk

    .

  148. arc

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

  149. mjk

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

  150. arc

    Google calendar says time remains the same for next week

  151. moparisthebest

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

  152. mjk

    Hmm

  153. MattJ

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

  154. MattJ

    We have a few of those "slots" in XEPs

  155. emus

    > 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

  156. ralphm

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

  157. emus

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

  158. ralphm

    I sent you his e-mail address

  159. moparisthebest

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

  160. moparisthebest

    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

  161. emus

    ralphm: thx

  162. mjk

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

  163. mjk

    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 ¯\_(ツ)_/¯

  164. mjk

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

  165. moparisthebest

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

  166. moparisthebest

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

  167. moparisthebest

    Maybe "ipdemands" hehe

  168. mjk

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

  169. moparisthebest

    "connectables"

  170. moparisthebest

    make no one happy... :)

  171. mjk

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

  172. qy

    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?

  173. qy

    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

  174. moparisthebest

    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 :/

  175. moparisthebest

    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

  176. qy

    Neat

  177. moparisthebest

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

  178. Sam

    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.

  179. moparisthebest

    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

  180. qy

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

  181. MattJ

    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.

  182. moparisthebest

    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

  183. MattJ

    Looks like it hasn't changed at all for years

  184. moparisthebest

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

  185. moparisthebest

    incoming as in sasl external authentication

  186. MattJ

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

  187. MattJ

    Not a helpful statement, I know

  188. moparisthebest

    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

  189. MattJ

    That's how it would read, yes

  190. moparisthebest

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

  191. mjk

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

  192. moparisthebest

    that sounds like an awesome spam tool :D

  193. moparisthebest

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

  194. Zash

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

  195. mjk

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

  196. moparisthebest

    well, good :)

  197. qy

    > 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

  198. qy

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

  199. moparisthebest

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

  200. moparisthebest

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

  201. qy

    Right, yeah

  202. mjk

    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...

  203. qy

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

  204. qy

    mjk: That is doable actually

  205. qy

    TRANSPort

  206. moparisthebest

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

  207. mjk

    qy: it is, just not the default conf

  208. qy

    Lol

  209. moparisthebest

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

  210. qy

    Not as i'm aware

  211. mjk

    Hmm right

  212. moparisthebest

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

  213. moparisthebest

    but... who wants to do that

  214. mjk goes back to the drawing board

  215. moparisthebest

    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?

  216. qy

    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

  217. qy

    So without mod_onions you can't make that iteration

  218. Sam

    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?

  219. moparisthebest

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

  220. moparisthebest

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

  221. moparisthebest

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

  222. qy

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

  223. moparisthebest

    "problem solved" :)

  224. qy

    _dusts hands_

  225. mjk

    Are there Rust libraries for generating Lua bindings? :3

  226. moparisthebest

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

  227. Link Mauve

    mjk, yes, see the mlua crate for instance.

  228. mjk

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

  229. moparisthebest

    yes that's what I mean

  230. mjk

    Aha

  231. mjk

    Then I'm content

  232. Zash

    (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)

  233. Link Mauve

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

  234. moparisthebest

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

  235. moparisthebest

    so prosody mod_onions requires dialback then

  236. Zash

    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

  237. mjk

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

  238. MattJ

    Pushed a comment to mod_onions, thanks Zash

  239. MattJ

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

  240. moparisthebest

    haha thanks :) mini heart attack averted

  241. emus

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