XSF Discussion - 2023-08-20


  1. MSavoritias fae.ve

    > Basically is, just obviously need discovery for alternative transports, I've still gotta write a xep for some of that A disco like feature for trasports you mean?

  2. MSavoritias fae.ve

    I was just think of referring people to xeps like quic for individual transports instead of having one at the core

  3. qy

    xmpp 2.0

  4. qy

    This is a thing?

  5. moparisthebest

    MSavoritias fae.ve: uh like, I need to connect to bob.com , how to I determine all the ways I can do that? https://github.com/moparisthebest/xmpp-proxy/blob/master/contrib/host-meta/xep-0156-proposed-minimal.json is my proposal for updating xep-0156 (or a new xep superseding it), already implemented and working in xmpp-proxy, just gotta write it up in xep form and start the discussions

  6. MSavoritias fae.ve

    hmm. so a way of asking the identifier what ways they support to connect. and for them to advertize them. What do you query though? DNS, domain, jid, DID?

  7. MSavoritias fae.ve

    the idea sounds exactly like what i had in mind btw

  8. singpolyma

    qy: just a meme

  9. qy

    Heh

  10. moparisthebest

    MSavoritias fae.ve: the rules of where it is etc are https://xmpp.org/extensions/xep-0156.html#example-2 my proposal will just add more fields and say "if the top level 'xmpp' object exists, you SHOULD NOT" continue to use other ways to look up connection methods, ie don't bother with srv/posh/host-meta.xml etc"

  11. moparisthebest

    MSavoritias fae.ve: the rules of where it is etc are https://xmpp.org/extensions/xep-0156.html#example-2 my proposal will just add more fields and say "if the top level 'xmpp' object exists, you SHOULD NOT continue to use other ways to look up connection methods, ie don't bother with srv/posh/host-meta.xml etc"

  12. MSavoritias fae.ve

    qy, i used it as shorthand for: "If we ever update the RFC in a way that requires adoption due to incompatible changes"

  13. MSavoritias fae.ve

    the core RFC that is

  14. qy

    Yeah

  15. MSavoritias fae.ve

    moparisthebest, ah sure. sounds interesting in an http context. i was more wondering in generic way. Like for example a xmpp.xml file with a standardized structure that can be seen somewhere. and then you query it for supported ways to connect to it.

  16. pep.

    > moparisthebest> I need to connect to bob.com , how to I determine all the ways I can do that? So the way to determine how to connect to an XMPP server is to first connect to it via HTTP :P

  17. pep.

    I wonder if HTTP will ever have something like this but in reverse, with XMPP

  18. qy

    I vote for less things using HTTP, not more...

  19. moparisthebest

    pep., qy: that's how it's always been since xep156 and POSH, if you can come up with a non-https way that is actually achievable today (ie, doesn't rely on DNSSEC or new DNS records we have no chance of getting adopted) then I'd be really happy about it, I've failed at that though

  20. qy

    Finger

  21. qy

    The thing that came before "web"finger :p

  22. moparisthebest

    > moparisthebest, ah sure. sounds interesting in an http context. i was more wondering in generic way. > Like for example a xmpp.xml file with a standardized structure that can be seen somewhere. and then you query it for supported ways to connect to it. MSavoritias fae.ve: the structure/payload doesn't matter much and is the easy part, the "somewhere" while retaining security (so you aren't MITM'd is the hard part

  23. moparisthebest

    > moparisthebest, ah sure. sounds interesting in an http context. i was more wondering in generic way. > Like for example a xmpp.xml file with a standardized structure that can be seen somewhere. and then you query it for supported ways to connect to it. MSavoritias fae.ve: the structure/payload doesn't matter much and is the easy part, the "somewhere" while retaining security (so you aren't MITM'd) is the hard part

  24. lovetox

    moparisthebest, but why a new file instead of host meta xml?

  25. lovetox

    whats the rational behind this?

  26. moparisthebest

    > Finger qy: I only know it by name, does it help or are you joking :D

  27. lovetox

    ah the json exists anyway in the xep i see

  28. lovetox

    so you plan to change the format of the json?

  29. moparisthebest

    lovetox: well it's not a new file, always been in xep-0156, the rationale for extending the json instead of the XML is because we don't control the schema, extending it becomes annoying

  30. moparisthebest

    Plan to extend the format of the json in a backwards compatible way yes

  31. singpolyma

    > pep., qy: that's how it's always been since xep156 and POSH, if you can come up with a non-https way that is actually achievable today (ie, doesn't rely on DNSSEC or new DNS records we have no chance of getting adopted) then I'd be really happy about it, I've failed at that though Please don't ever use POSH

  32. pep.

    moparisthebest, I get 0156 when used in the browser say, or when the method that's going to be used is bosh or ws. It makes less sense when it's not the case

  33. lovetox

    whats wrong with posh?

  34. moparisthebest

    pep.: So how do we communicate pinned public keys or ech keys?

  35. moparisthebest

    POSH is less than ideal because: 1. It's an additional request 2. It pins certificates which change constantly rather than keys which never have to change

  36. moparisthebest

    But we need a replacement before we can say don't use it

  37. Zash

    MattJ and I had some thoughts around replacing POSH key stuffs with a name, like the thing where you trust a DNSSEC-secured SRV 'target' value to match a certificate

  38. moparisthebest

    Zash: like in a TXT record, only usable with DNSSEC?

  39. moparisthebest

    I mean if we have DNSSEC we don't need POSH, we have DANE

  40. moparisthebest

    I'm hoping one day we can assume everyone has DNSSEC, but until then I can't come up with a better solution than https, sadly

  41. Zash

    moparisthebest, https-secured delegation by name

  42. Zash

    where POSH is https-secured delegation by key

  43. moparisthebest

    Ah got it, so still https, that also could be rolled into my xep156 json proposal

  44. pep.

    Ah because you're also changing xml to json in that proposal :p

  45. pep.

    great

  46. moparisthebest

    Right now to make an XMPP connection: 1. Look up starttls srv records 2. Look up direct TLS srv records 3. Fetch posh json over https 4. Fetch host-meta XML over https 5. Fetch host-meta json over https 6. No method yet to discover quic, we need one My proposal: 1. Fetch host-meta json over https, if it's this new version, you are done Then we add quic or future things in that

  47. moparisthebest

    pep.: no, it already has json

  48. pep.

    It has both and only XML is mandatory no?

  49. moparisthebest

    Right, the json is just a SHOULD now

  50. moparisthebest

    I have a proposal for updating the XML instead but as I said, not our schema, so it involves namespaced attributes etc which is less than ideal

  51. pep.

    namespaced attributes is fine. One day people will get over them :)

  52. pep.

    namespaced attributes are fine. One day people will get over them :)

  53. Zash

    Isn't the JSON actually JSON-LD?

  54. moparisthebest

    I don't really care *which* format, I do care that there's only 1 and we don't need to fetch them all

  55. pep.

    Why was the DNS stuff removed from 156 btw?

  56. pep.

    Is it about DNS or how it was specified?

  57. Zash

    TXT record without any security guarantees

  58. pep.

    Ok, so it was missing at least DNSSEC?

  59. Zash

    It changed the reference hostname without DNSSEC or something to secure that

  60. Zash

    You must have a secure chain from what the user typed to the name in the certificate.

  61. lovetox

    moparisthebest, i agree that one single point to get all the information would be nice

  62. lovetox

    and i assume we dont need to do any dns queries anymore, because the file contains all ips

  63. lovetox

    it would be cleaner indeed, though i have to say its not that complicated for most client as you make it in your example

  64. lovetox

    for example a client like gajim which does not support POSH, its a single http query to the hostmeta xml

  65. lovetox

    and then simply start connecting, dns queries are abstracted away by the network lib

  66. lovetox

    of course they happen, but from an impl point in Gajim, i implemented a single http query, to get starttls, directls, websocket working

  67. Zash

    if you ignore backwards compat

  68. lovetox

    yeah .. a client has to impl that old way anyway

  69. lovetox

    but yeah no reason to not start improving things

  70. Zash

    I don't want to require domain apex .well-known either.

  71. lovetox

    from a operator standpoint it becomes harder, because the need to maintain a valid http cert and a valid xmpp server cert

  72. Menel

    Not all severs have https on port 443

  73. Menel

    But as long as nothing is stopping a client from jsut connecting to a standard xmpp port, it would be OK I guess. Most clients jsut don't need any connection info, they can jsut try connect the default way.

  74. singpolyma

    IMO anything using https is a non starter

  75. singpolyma

    Especially for security stuff

  76. Menel

    Why

  77. Menel

    Ist most stuff these days on https only?

  78. singpolyma

    Menel: not xmpp stuff

  79. singpolyma

    We don't control anything about HTTP so shackling our stuff to that, especially important stuff, is just asking for trouble

  80. moparisthebest

    > Why was the DNS stuff removed from 156 btw? pep.: https://www.moparisthebest.com/slides/xmpp-connectivity-security-13JUL2023.html#(16) and next couple slides

  81. moparisthebest

    > We don't control anything about HTTP so shackling our stuff to that, especially important stuff, is just asking for trouble singpolyma: I vaguely agree, except https is widely deployed, secure, and "too big to fail" so again, I don't see a better alternative right now

  82. moparisthebest

    We can either: 1. Build the ideal system requiring DNSSEC+Dane that can't be implemented now, and maybe never will be 2. Build a less than ideal system that will work now, and doesn't preclude #1 I'm working on #2

  83. lovetox

    but what is the core problem you are trying to solve

  84. Zash

    You're working on a "temporary" thing? It'll be permanent and forever if adopted :(

  85. lovetox

    i mean there are multiple srv records defined to find the right server and a xml, yeah it could be more pretty, but what does not work currently that you are trying to solve?

  86. moparisthebest

    Zash: haha I'm definitely not naive enough to call it temporary

  87. moparisthebest

    > but what is the core problem you are trying to solve lovetox: 1 method to discover all existing and new connection methods, and additional things we don't have yet like pinned public keys and ech

  88. lovetox

    yeah so lets put new or alternative connection methods into 0156

  89. lovetox

    that what it is for

  90. lovetox

    i dont see the problem in extending the xml, and the json

  91. lovetox

    and if clients then requesting the json or xml, first before trying anything, is a thing clients can do if they want

  92. lovetox

    the standard detection method for normal connection will never go away, and everything else which is not defined in 6120 should go in 0156

  93. MSavoritias fae.ve

    > We can either: > 1. Build the ideal system requiring DNSSEC+Dane that can't be implemented now, and maybe never will be > 2. Build a less than ideal system that will work now, and doesn't preclude #1 > > I'm working on #2 it will never be with that attitude. what we need is correct, secure solutions imo. and yeah i agree that http is a non starter. for upload too but thats another discussion

  94. qy

    > We can either: > 1. Build the ideal system requiring DNSSEC+Dane that can't be implemented now, and maybe never will be > 2. Build a less than ideal system that will work now, and doesn't preclude #1 > > I'm working on #2 Why cant be implemented?

  95. Ellenor Malik

    > qy a Γ©critΒ : > Why cant be implemented? DNS registrars would need to support it

  96. MSavoritias fae.ve

    noob question: why cant we "just" knock on the server we want bob.com or whatever. in a standard port and connection. xmpp over tls probably. and then the server can present a information on what they want to communicate with?

  97. MSavoritias fae.ve

    That would of course mean that all servers need to support tcp over tls

  98. pep.

    I also think that's ok. That's a lesser ask than all XMPP servers supporting HTTPS I think

  99. pep.

    And if at year 3015 we need another default method then we'll start drafting another spec for year 3096

  100. Menel

    πŸ‘

  101. Menel

    Demanding direct tls seems better then demanding https

  102. pep.

    I don't know if the "direct" was on purpose but that's not what I just agreed to :P

  103. MSavoritias fae.ve

    i think the main point is a universally supported connecting and port and then have the server present their preferences and support. the type of connection is to be discussed anyway

  104. MSavoritias fae.ve

    connection*

  105. lovetox

    MSavoritias fae.ve, i dont think thats what its about

  106. lovetox

    the standard defines the standard port and methods since forever, and everybody uses it

  107. lovetox

    what moparisthebest wants to solve is, that new alternative connection methods like quick not all generate their own way of discovery

  108. lovetox

    instead put discovery of everything thats not standard into one single point

  109. MSavoritias fae.ve

    yep. that was my point too.

  110. MSavoritias fae.ve

    why not have the server/client advertise it? instead of files over https?

  111. MSavoritias fae.ve

    that was my question

  112. qy

    >> qy a Γ©critΒ : >> Why cant be implemented? > DNS registrars would need to support it Do they not already implement dnssec? Not sure what dane is

  113. pep.

    qy, not all registrars do DNSSEC no :/

  114. pep.

    Like .im.

  115. pep.

    And I don't know about all the new tlds

  116. lovetox

    what does dnssec achieve? that i can trust the DNS record, anything more?

  117. pep.

    That's already an improvement

  118. Zash

    All new gTLDs must do DNSSEC so it's pretty much just .im that's falling behind

  119. pep.

    Ok

  120. MSavoritias fae.ve

    ah well that seems less horible than i thought

  121. Zash

    Maybe DoT/DoH can get you DNSSEC all the way into your client even

  122. moparisthebest

    > yeah so lets put new or alternative connection methods into 0156 lovetox: that's what I'm proposing, except it has 2 methods and I'm looking to cut that down to 1, I honestly don't care if the 1 is json or XML but with that schema it seems like json is easier

  123. moparisthebest

    > noob question: why cant we "just" knock on the server we want bob.com or whatever. in a standard port and connection. xmpp over tls probably. > and then the server can present a information on what they want to communicate with? MSavoritias fae.ve: that's literally what xep156 is

  124. moparisthebest

    You hit bob.com on TLS on port 443 and ask for all the info you need

  125. MSavoritias fae.ve

    with two caveats though to my understanding: It uses http and it uses a file for some reason

  126. MSavoritias fae.ve

    i was asking why not use something akin to disco and just have the server send stanzas with prefferend methods. instead of looking at files

  127. moparisthebest

    Minor details

  128. moparisthebest

    That's just a different encoding

  129. MSavoritias fae.ve

    yaeh its the same thing i agree. but it doesnt need a file or http. and can be done natively by xmpp over tls

  130. MSavoritias fae.ve

    direct or not

  131. MSavoritias fae.ve

    and we can be sure its secure since we check the same way we always check when we connect to servers. then DNSSEC is not needed either

  132. MSavoritias fae.ve

    but maybe i am missing something

  133. MSavoritias fae.ve

    DNSSEC would be nice of course. but its not as horribly insecure as checking random txt fields in DNS

  134. moparisthebest

    I just really don't think it gives any advantages over https, and it has some major disadvantages

  135. pep.

    What are the disadvantages?

  136. moparisthebest

    1. That's an additional (7th) required step to get connection methods, as opposed to just adding more info to one of the existing ones 2. You'd still want it over TLS on 443 to appear as https for firewall reasons 3. Web clients would need a different method 4. As a client, instead of using your existing http lib or a standard one, you have to implement a custom not-quite-xmpp and connect anonymously and query to get the same payload https would give you 5. As a server you have to implement the same custom not-quite-xmpp that supports anonymous connections and returning the same file https would serve as a stanza, while ensuring nothing sent on this connection would route anywhere else

  137. MSavoritias fae.ve

    i am saying to replace all of them though. there is no files to check or dns records. you always go to the same port

  138. MSavoritias fae.ve

    but yeah http clients wouldnt work :/

  139. MSavoritias fae.ve

    but wait why is it not xmpp what i am saying? cant i connect to another server and start exchanging stanzas if we check each otherst certificates?

  140. pep.

    moparisthebest, connect to your XMPP server on :5222 or :5269, read <alt-stuff/> in features, choose your alternative method or go ahead. What's the issue with this?

  141. MSavoritias fae.ve

    yep thats what i am proposing ^

  142. pep.

    Web clients be web clients. You can _also_ complete 156 if you want, but why do we continue forcing everyone to do HTTP

  143. lovetox

    because its kind of out of band which everyone can do

  144. pep.

    We can also do in-band

  145. pep.

    Surprise

  146. lovetox

    no, because not everyone can do it, as you stated yourself

  147. pep.

    Maybe we should just switch to HTTP+JSON, since everyone can do it

  148. moparisthebest

    > moparisthebest, connect to your XMPP server on :5222 or :5269, read <alt-stuff/> in features, choose your alternative method or go ahead. What's the issue with this? What if none of these are open ports? Discovery after connecting isn't so helpful

  149. lovetox

    what you propose, is adding another way of discovery

  150. pep.

    moparisthebest, well you also rely on https/443 being open

  151. lovetox

    additional, to everything that exists now, it does not get rid of anything

  152. moparisthebest

    pep.: it always is, well, specifically if your network is not completely locked down, it always is

  153. MSavoritias fae.ve

    not if i dont have http

  154. moparisthebest

    What do you mean?

  155. MSavoritias fae.ve

    if i dont have the https port open

  156. MSavoritias fae.ve

    and i have a pure xmpp client

  157. moparisthebest

    I don't know how to answer that "what if I want to do something but refuse to do it"

  158. pep.

    what?

  159. MSavoritias fae.ve

    if this xep was restricted to "web clients finding ways to connect" that would make it more clear

  160. moparisthebest

    Besides isn't your XMPP server already listening on TLS on 443 ? Mine is

  161. MSavoritias fae.ve

    no

  162. MSavoritias fae.ve

    why would it be?

  163. moparisthebest

    Why have a different way for web clients and other clients to connect? Seems silly

  164. pep.

    I understand 0156 being what it is, because it's here to advertize stuff that mostly web clients would use, so it makes sense that it's readable by web clients. That's not what we're talking about here

  165. pep.

    moparisthebest, mine isn't

  166. moparisthebest

    > why would it be? So...I can connect to it from everywhere of course

  167. pep.

    And probably won't

  168. MSavoritias fae.ve

    i agree that ports are useless but we are not fixing the OSI system here :P

  169. MSavoritias fae.ve

    i had no idea that its expected for xmpp servers to be open to the https port though

  170. MSavoritias fae.ve

    not that i will open that port anyway

  171. pep.

    Well just like everyone expects files to be exchanged over HTTP in XMPP nowadays..

  172. pep.

    Another funny habit

  173. moparisthebest

    My unpopular opinion coming through: All internet traffic should go over TLS (or quic) on port 443 to appear as close as possible to https and be as hard to block as possible

  174. moparisthebest

    Native clients shouldn't "well I don't need to support web sockets" ok if you hate your users

  175. MSavoritias fae.ve

    sure. but maybe we can find a way for other ways to work too

  176. moparisthebest

    Signal and WhatsApp don't refuse to go around firewalls so their users can connect, XMPP clients shouldn't either

  177. MSavoritias fae.ve

    but thats up to the client. a XEP shouldn't dictate that

  178. pep.

    signal and WhatsApp don't have the same political agenda though. They just want lock in users

  179. moparisthebest

    XMPP is great, everyone should use it, but it doesn't matter in the least how great it is if users can't connect

  180. pep.

    signal and WhatsApp don't have the same political agenda though. They just want to lock in users

  181. moparisthebest

    And if users can't connect because some standards people decided TLS on 443 wasn't pure enough or something, well frankly, that's just stupid

  182. MSavoritias fae.ve

    im not saying we cant do it. sure where the threat model applies do it. but dont make it mandatory

  183. lovetox

    as i understand it, alternative connection methods mean, methods like websocket or quick

  184. moparisthebest

    My "political agenda" in XMPP is to make connecting: 1. Secure 2. Hard to block as possible, I almost wrote impossible to block, but while that's the goal it's... Impossible :) 3. As easy as possible

  185. lovetox

    if i implement a client that only speaks quick

  186. lovetox

    where do i connect?

  187. lovetox

    on 5222? to get another port inband?

  188. lovetox

    does this even work?

  189. lovetox

    can one port speak multiple protocols?

  190. moparisthebest

    My "political agenda" in XMPP is to make connecting: 1. Secure 2. As reliable/Hard to block as possible, I almost wrote impossible to block, but while that's the goal it's... Impossible :) 3. As easy as possible

  191. pep.

    Well http2 is still on 443

  192. moparisthebest

    http3 is on port 443 UDP

  193. moparisthebest

    Though now http3 supports discovering and use of different ports

  194. pep.

    Via dns stuff?

  195. pep.

    Or in-band?

  196. moparisthebest

    I don't actually expect anyone to use it though because of stupid firewalls

  197. moparisthebest

    Actually both I think?

  198. pep.

    Well there your go :P

  199. moparisthebest

    I think there's a header and you can do it in the https DNS record, but I'm not sure

  200. moparisthebest

    Here's the header https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Alt-Svc

  201. pep.

    Yeah the "new SRV"

  202. moparisthebest

    This one is the new srv, looks like indeed it supports custom ports: https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/12/

  203. moparisthebest

    <minirant>it's great they named that https because now it's impossible to search for</minirant>

  204. pep.

    Well actors around it have no intention of using anything else anyway so why bother

  205. pep.

    (/s)

  206. moparisthebest

    Maybe I'll write 2 conflicting MRs for xep156, one extending json and deprecating XML, and the other extending XML and deprecating json, and everyone can battle it out on the mailing list lol

  207. pep.

    Why not continue as it is already and update both, only mandating that XML be supported?

  208. pep.

    Do you actually want it to change?

  209. moparisthebest

    If XML must exist why even have json at all? And vice-versa ?

  210. moparisthebest

    Web client or not can implement code for just the mandatory one, why would you ever also implement code for the other?

  211. pep.

    I wonder if this is because of the editorial process of just because people resist change that we feel compelled to include so many changes in a single patch

  212. pep.

    moparisthebest, I also wonder. That's why I never bothered to host the .json

  213. moparisthebest

    Or we can resurrect a modified HACX lol https://xmpp.org/extensions/inbox/hacx.html But that's the same downside of introducing a 7th required discovery method

  214. pep.

    (I don't even have the 0156 file atm, I checked)

  215. moparisthebest

    I still prefer that XEP name though lol

  216. MSavoritias fae.ve

    Do i even want to ask why SRV wasnt used?

  217. lovetox

    the xml was specified and published, then probably someone came along and said, i want json

  218. lovetox

    and now you want xml gone ..

  219. lovetox

    thats just not how the standards process can work ..

  220. lovetox

    if we do this then every XEP is a moving target

  221. pep.

    Well every XEP is

  222. lovetox

    no not really ..

  223. pep.

    something something eventual consistency

  224. moparisthebest

    Everything that isn't final is

  225. lovetox

    there is no compelling reason why you dont extend the xml, the argument "the schema is not ours" is not compelling

  226. pep.

    moparisthebest, and even stuff that's final is being updated by other specs

  227. moparisthebest

    Right I find extending the XML more annoying but I'm happy to be overruled

  228. Zash

    Break from host-meta?

  229. Zash

    Isn't it acutally neither XML nor JSON? It's RDF?

  230. moparisthebest

    The only thing I *really really* want is a method to signal "don't also look up all the other ways"

  231. pep.

    moparisthebest, that's weird though because extending/creating XML is what we do all the time here :(

  232. moparisthebest

    If we can get that by extending 156 instead of introducing network call #7 that would be ideal

  233. pep.

    Network call #7? I still don't get this

  234. MSavoritias fae.ve

    Yeah who wanted yet another call?

  235. moparisthebest

    pep.: iirc we've stayed away from attribute namespaces so far though, maybe that's no longer a valid concern, I can't say, I know where you stand on it :)

  236. pep.

    :)

  237. MSavoritias fae.ve

    Attribute namespaces as in xml namespaces?

  238. pep.

    XML attribute namespaces

  239. moparisthebest

    > Right now to make an XMPP connection: > 1. Look up starttls srv records > 2. Look up direct TLS srv records > 3. Fetch posh json over https > 4. Fetch host-meta XML over https > 5. Fetch host-meta json over https > 6. No method yet to discover quic, we need one Ok depending maybe network call #6, my point being we can either not add to these steps and extend 156, or add another to these steps instead, and imho it'd be slightly preferable to just add to 156

  240. MSavoritias fae.ve

    Ah thanks. Will look it up

  241. MSavoritias fae.ve

    Well since we want it to work for http stuff for sime reason removing them in favor of knocking wouldnt work either :/

  242. qy

    I think i agree with whoever said this should all just go in <features/>

  243. moparisthebest

    Oh right another vote against the XML is the example XML from the RFC is actually invalid lol https://github.com/moparisthebest/xmpp-proxy/blob/master/contrib/host-meta/rfc6415.xml

  244. pep.

    moparisthebest, make 0156 for web clients only, still do up to and including #3, and have <alt-svc/> be served in stream features :P

  245. moparisthebest

    Vs https://github.com/moparisthebest/xmpp-proxy/blob/master/contrib/host-meta/rfc6415.but-valid.xml

  246. pep.

    moparisthebest, fix the XML? That's a bit weird to invalidate something just because an example is borked?

  247. moparisthebest

    pep.: and then quic? And how do I get pinned public keys or the ech key before connecting?

  248. pep.

    You don't. Just like you don't for https

  249. moparisthebest

    ech is a massive feature for privacy by the way

  250. pep.

    ech?

  251. MSavoritias fae.ve

    Encrypted client hello

  252. pep.

    When connecting to https/443, you don't get it either right?

  253. Zash

    Is it finished yet?

  254. moparisthebest

    ^ tldr hides your sni and alpn

  255. Zash

    pep., you do because you did DNS over HTTPS to get the HTTPS record which contains that...................

  256. pep.

    lol

  257. Zash

    it'll be HTTPS all the way down :(

  258. pep.

    Yeah no way

  259. moparisthebest

    As usual not yet finished but already deployed in all browsers for years https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.html

  260. Zash

    Browsers

  261. Zash

    But no, SRV records, or SRV certificates, that they refuse!

  262. moparisthebest

    Next feature XMPP clients and servers need to copy from browsers: 15 CVEs and patch releases per week so we can assume everyone is always running the latest and move fast

  263. moparisthebest

    /s

  264. pep.

    Even with money I wouldn't want this cadence

  265. MSavoritias fae.ve

    I still think adding alternative connections in features makes the most sense

  266. MSavoritias fae.ve

    And we can the http clients play with their broken stuff in a xep in the corner

  267. moparisthebest

    Advertising connections and ech and pinned keys etc can't come after the connection, I need all that stuff to make the connection

  268. pep.

    moparisthebest, it can be used next connection

  269. pep.

    Just like you do with HTTP..

  270. moparisthebest

    Not if you can't make the first one

  271. pep.

    I guess climate change regulations should also go over :443/https. We wouldn't have that many issues.. (someone please turn off the heat)

  272. qy

    😬

  273. Zash

    If you can't make the first one then you should complain to your network admin that they shouldn't be blocking everything except 443.

  274. Zash

    Otherwise it'll just keep spreading

  275. MSavoritias fae.ve

    ^

  276. Zash

    Or rather spread faster because there's no resistance

  277. Zash

    Until the day everything is over 443 because that's all that works and we've added another layer to the stack that can never be removed.

  278. pep.

    I'd go further and say, if it's possible for you, quit and bully companies that do this.

  279. qy

    Its understandable to make it possible for alternate services to be first-class, though

  280. qy

    If your "network admin" is the CCP you cant exactly complain

  281. Zash

    Not with that attitude!: P

  282. Zash

    Not with that attitude! :P

  283. singpolyma

    >> Right now to make an XMPP connection: >> 1. Look up starttls srv records >> 2. Look up direct TLS srv records >> 3. Fetch posh json over https >> 4. Fetch host-meta XML over https >> 5. Fetch host-meta json over https >> 6. No method yet to discover quic, we need one > > Ok depending maybe network call #6, my point being we can either not add to these steps and extend 156, or add another to these steps instead, and imho it'd be slightly preferable to just add to 156 Only 1 and 2 are legitimate here. Shouldn't do the others

  284. qy

    I can get behind quic

  285. MSavoritias fae.ve

    Quic makes the whole thing easier yeah

  286. MSavoritias fae.ve

    Including the starttls and direct tls and stuff

  287. MSavoritias fae.ve

    (Which dont exist)

  288. pep.

    Now I guess we'll have to fight to allow UDP stuff through corporate bul^Wfirewalls

  289. qy

    :D

  290. singpolyma

    pep.: Proxy it over https

  291. singpolyma

    ;)

  292. pep.

    Right

  293. Trung

    Not all web clients need #3,#4,#5 😁 However, #6 would make XMPP very sexy πŸ˜‰

  294. singpolyma

    Yeah, 3/4/5 don't really seem like reasonable things to do

  295. singpolyma

    6 I can't comment on as it's unspecified ;)

  296. moparisthebest

    > If you can't make the first one then you should complain to your network admin that they shouldn't be blocking everything except 443. > I'd go further and say, if it's possible for you, quit and bully companies that do this. While I understand the sentiment, this is the same as just telling people to use WhatsApp

  297. moparisthebest

    > 6 I can't comment on as it's unspecified ;) singpolyma: XMPP over QUIC is specified https://xmpp.org/extensions/xep-0467.html Connection discovery for it is not yet... That's part of what we are discussing here :)

  298. singpolyma

    Sure. And for some reason you need key material just to make a quic connection or something that's the hard part?

  299. moparisthebest

    No, we can absolutely just do _xmppq-client._udp.example.org srv lookups for QUIC, but seperately we need: 1. Ech keys before making the connection 2. Pinned public TLS keys 3. Connection discovery for s2s over websockets

  300. moparisthebest

    So do we keep piling on the partial solution or come up with a single solution for everything?

  301. moparisthebest

    So do we keep piling on the partial solutions or come up with a single solution for everything?

  302. singpolyma

    Why do we need 1 or 2? Is that related to quic somehow?

  303. moparisthebest

    Nope entirely unrelated, we need them for regular TLS too

  304. singpolyma

    Ok. I think that's a seperate discussion then

  305. singpolyma

    Pinned TLS sounds like TLSA to me so already solved?

  306. moparisthebest

    If DNSSEC was widely deployed sure, again the now vs preferred future :)

  307. moparisthebest

    As these are "things needed to connect" I don't think it should be a seperate discussion, that's kinda my whole point

  308. singpolyma

    You can't do TLS pin without an alternative auth system. DNSSEC is the only viable option I'm aware of for that

  309. singpolyma

    If you can't do DNSSEC there's no way to auth your pin

  310. singpolyma

    Also DNSSEC is widely deployed? Like, you just click the button to turn it on

  311. singpolyma

    Unless you're on a bad TLD

  312. singpolyma

    If you publish a pinned TLS key over HTTPS you just ha e a recursive problem how to pin the TLS key used for HTTPS? So doesn't solve anything

  313. moparisthebest

    > You can't do TLS pin without an alternative auth system. DNSSEC is the only viable option I'm aware of for that You can have a "trusted" system perform DNS for you from multiple independent data centers around the globe simultaneously and then cryptographically sign that they all got the same answer within the last 90 days It's not perfect, but it's better than you can do alone

  314. singpolyma

    Sure, could do that too. So TLSA still the solution

  315. moparisthebest

    That's the CA system we have now

  316. singpolyma

    Do they even check from multiple data centers for letsencrypt?

  317. moparisthebest

    Yep

  318. singpolyma

    I wouldn't trust them to actually be doing it right. But we can always hope

  319. moparisthebest

    https://letsencrypt.org/2020/02/19/multi-perspective-validation.html

  320. moparisthebest

    Right, it's the best we can hope for outside of DNSSEC

  321. singpolyma

    Anyway, so SRV for quic, TLSA if you want to pin. ECH keys before connection... TXT I guess? It's basically the same problem as TLSA but not gonna invent a new DNS thing so I guess TXT

  322. moparisthebest

    And then s2s over websocket? And then whatever new transport MSavoritias fae.ve is doing?

  323. moparisthebest

    It'd be very nice if we could make getting all these 1 network call instead of 8 or 9 or whatever we are up to now

  324. singpolyma

    I mean a DNS lookup is hardly a "network call" it's a udp packet

  325. singpolyma

    I can probably do a dozen or more DNS lookups in the time it takes to do one https connection

  326. Zash

    in _parallel_ !

  327. singpolyma

    Indeed

  328. singpolyma

    I don't really see a use case for s2s over websocket, but I'm not against it being specced for anyone who wants it

  329. moparisthebest

    Also already specced sans discovery https://xmpp.org/extensions/xep-0468.html

  330. singpolyma

    Does it need discovery? If you're using websockets I expect you know you're doing that

  331. singpolyma

    Not that adding SRV for it is hard but πŸ€·β€β™‚οΈ

  332. moparisthebest

    Oh right the other reason, DNSSEC SRV secure delegation actually doesn't work with Direct TLS or QUIC, I believe Zash is the expert here but you have no idea which domain to put in SNI right?

  333. moparisthebest

    It's not a security problem, you just don't know how the server is configured, but most commonly one will fail and the other won't

  334. moparisthebest

    You can't do srv for websocket for ^ reason *and* no way to return the path

  335. singpolyma

    You want to do websocket with a *path*???

  336. Zash

    It's a HTTP GET request, so you need a path component.

  337. singpolyma

    There's a whole nightmare with how SRV+DANE is specced to work the opposite way that certs work in XMPP

  338. singpolyma

    Zash: it's not though. It just has a header that looks like one to get through proxies. There's no reason to use a path with websockets

  339. Zash

    In Prosody, it's handled and routed as any other HTTP request, except it doesn't have a response because the socket gets hijacked and connected to mod_c2s

  340. Zash

    I wouldn't be upset if we did a take 2 on XMPP+DANE

  341. moparisthebest

    > I mean a DNS lookup is hardly a "network call" it's a udp packet Also I hate to tell you but *trigger warning* DNS is a seperate TLS connection best case and usually an HTTPS GET these days, only way to do it privately

  342. singpolyma

    I don't fully hate the current SRV+DANE spec now that Zash explained it to me, but it's not possible to do both DANE and CA-verification for the same domain right now I think, which annoys me

  343. Zash

    Also awkward that SNI only carries a single identifier.

  344. Zash

    Can't say that you could validate the domain and/or the hostname, only one or the othre.

  345. singpolyma

    Don't need sni if you do starttls, but I know that's out of Vogue

  346. Zash

    You can do SNI in both cases, not sure what you end up conjuring if you send something else in SNI than in stream to=

  347. moparisthebest

    > Also awkward that SNI only carries a single identifier. Right, this is the problem

  348. singpolyma

    moparisthebest: it's not a problem. It's just annoying. It means that if you need SRV then you have to pick DANE or CA can't do both

  349. Zash

    Put both names in SANs. :)

  350. Zash

    Isn't it actually a good thing that you can't do both, as you double the attack surface, or somesuch.

  351. Zash

    But then I think you can do both anyway.

  352. moparisthebest

    You have 2 domains you will accept a certificate for, but you can only tell the server one of them, that's the problem

  353. Zash

    maybe with DANCE we can use the presence of that to just ignore SNI and ... something

  354. Zash

    I find that more of a problem, that you can only do DANE in one direction

  355. moparisthebest

    For validating incoming connections you can just look up all the possible TLSA for outgoing and see if one matches no?

  356. Zash

    That's what I did in the old defunct DANE module for Prosody

  357. singpolyma

    Probably fine

  358. Zash

    Not really possible when you're just telling OpenSSL to do DANE for you, unless you _also_ duplicate all of it for client certificate auth.

  359. moparisthebest

    ah ew

  360. singpolyma

    I'm surprised openssl is dane aware at all, but obviously it won't do everything we need for xmpp yeah.

  361. Zash

    DANE is the standard in email now, don't listen to anyone who mentions MTA-STS :)

  362. moparisthebest patiently waits until prosody.im and conversations.im and sure.im and all the others support DNSSEC πŸ˜­πŸ‘΄βš°οΈ

  363. Zash

    I think the idea with DANCE is that the initiator does the DNS lookups and includes in the handshake to the responder doesn't have to do them, which seems nice.

  364. Zash

    I think the idea with DANCE is that the initiator does the DNS lookups and includes in the handshake so the responder doesn't have to do them, which seems nice.

  365. singpolyma

    moparisthebest: baby steps πŸ™‚

  366. moparisthebest

    singpolyma: where are you seeing steps taken

  367. singpolyma

    Here where we're actually discussing how to get a single Dane impl do even exist :P

  368. moparisthebest

    > I think the idea with DANCE is that the initiator does the DNS lookups and includes in the handshake so the responder doesn't have to do them, which seems nice. That does seem nice

  369. moparisthebest

    Doesn't prosody do Dane?

  370. singpolyma

    I'm gonna start warning non dnssec domains in the next year sometime also

  371. singpolyma

    > Doesn't prosody do Dane? No

  372. Zash

    "do dane"?

  373. singpolyma

    Zash literally just said there's not even a decided way to do bidirectional DANE

  374. singpolyma

    So obviously not doing it yet heh

  375. Zash

    bidirectional DANE is DANCE :)

  376. Zash

    or, both?

  377. Zash

    hm

  378. moparisthebest

    What did the prosody Dane module do then?

  379. Zash

    Prosody does regular DANE if you install the latest development version and the recommended but technically optional dns library and also flip some undocumented switches.

  380. moparisthebest

    So outgoing only?

  381. Zash

    moparisthebest, DNA

  382. Zash

    or whatsitcalled

  383. Zash

    I don't remember the details, this is 2014 era events.

  384. Zash

    The older module did the thing where it looked up SRV and TLSA records for both client and server auth and validated certs itself

  385. moparisthebest

    xmpp-proxy has most needed to do Dane in both directions except my DNSSEC lib was missing something required and I recall making an issue and forgetting about it πŸ˜•

  386. moparisthebest

    Yes, that way, so what's the new support do differently?

  387. Zash

    The new stuff is regular DANE done in the code that handles any network connection attempts, so applies to https too, not really tied to s2s in any way.

  388. moparisthebest

    So lost support for validating incoming s2s then?

  389. Zash

    Yes

  390. Zash

    But also doesn't have to do certificate chain juggling or certificate format fiddlery

  391. Zash

    Or do async stuff in the middle of stuff to wait for DNS

  392. Zash

    But yeah, incomplete, hence disabled by default

  393. singpolyma

    Does the old module still work or really not?

  394. Zash

    Also requires that you have the dnssec-capable dns resolver library and dnssec-capable upstream (tho the resolver lib can do recursive resolution)

  395. Zash

    Dunno, I think it broke due to some async changes

  396. Zash

    Or because we deleted half of mod_s2s? I forget

  397. Zash

    2sleepy4code

  398. Zash

    https://modules.prosody.im/mod_s2s_auth_dane.html#compatibility

  399. Zash

    Ah yeah, the commit that deleted the part of mod_s2s that handles outgoing connections

  400. moparisthebest

    The ultimate plan in xmpp-proxy is to support DNSSEC locally, and probably while doing dns-over-tls to a known working resolver, like cloudflare or Google optionally

  401. singpolyma

    Yes. I have some ideas about similar with cheogram android to work around the "some resolvers are broken" problem that got dnssec stuff disabled in conversations before

  402. singpolyma

    Though since it's needed specifically in cases where the local network is super hostile I may hold my barf and use DoH

  403. moparisthebest

    Do it in xmpp-proxy then just embed it as your networking library in cheogram :P

  404. singpolyma

    That's definitely under consideration, yeah

  405. moparisthebest

    I can pass you my Java library that does this, works on openjdk on the desktop, but integrated with Cheogram on a real device it segfaults and I never set up an emulator to debug

  406. singpolyma

    I'm probably not going to tear my netstack out in this major version number anyway, but I'm keeping an open mind a out the future

  407. moparisthebest

    This was a one night "hey I wonder if this will work..." coding binge that ended in "install an Android emulator and figure out how to debug with it? Not that interested yet"