jdev - 2024-02-13


  1. moparisthebest

    > Sure. But given the choice of "well designed" and "well documented", I know which I'll pick first. dwd: always? https://www.iso.org/standard/61750.html

  2. moparisthebest

    That's all 5018 pages of the Microsoft ooxml spec 🀣

  3. Pyrox

    im the yawner

  4. Pyrox

    apologies, wrong channel

  5. Schimon

    Pyrox, I am a lawyer too! High five 🫸️

  6. Schimon

    Pyrox, I am a lawyer too! High five o/

  7. pep.

    How do I test tls/xmpp on :443 again with stuff like openssl s_client?

  8. pep.

    Not starttls

  9. Guus

    pep. are you referring to sslh that has some kind of magic byte detection?

  10. pep.

    Yeah I guess.

  11. pep.

    I just want to know if a host supports tls over 443 for xmpp

  12. pep.

    And I guess with setups like sslh I can't "just" -connect host:443

  13. Guus

    pep. maybe you're referring to ALPN?

  14. Guus

    that can be used to negotiate what protocol is being negotiated over TLS, iirc

  15. pep.

    Yeah I guess that's alpn. I wonder if I can specify it with openssl s_client

  16. Guus

    I do not know.

  17. pep.

    I can, -alpn

  18. pep.

    Thanks

  19. Guus

    anytime

  20. pep.

    Now to look for the value I need to put there..

  21. pep.

    "xmpp" gives me an error.

  22. pep.

    CONNECTED(00000003) 4027BA8E0A7F0000:error:0A000460:SSL routines:ssl3_read_bytes:reason(1120):ssl/record/rec_layer_s3.c:865:SSL alert number 120

  23. pep.

    Ok the alpn thing is "xmpp-client", but that doesn't help

  24. pep.

    If someone finds a way I'm happy to put that in https://wiki.xmpp.org/web/Tech_pages/XEP-0368 :x

  25. moparisthebest

    pep.: Yes it should be -alpn xmpp-client but make sure you are sending SNI too, maybe -sni ? If you still can't get it I'll try when at a computer later

  26. pep.

    Β« -servername val Set TLS extension servername (SNI) in ClientHello (default) Β» so I assume it's set to whatever hostname I give it in -connect. And nothing changes if I set it manually

  27. moparisthebest

    Unless something changed it definitely doesn't set it for you

  28. pep.

    Maybe this error is just telling me the host doesn't support it

  29. pep.

    Because Β« -alpn "http/1.1" Β» works

  30. pep.

    Yeah that was it

  31. pep.

    It works with some other host that I know support it

  32. pep.

    hah no it doesn't.. I just get the answer from the http server :D

  33. moparisthebest

    pep.: Works on my server that requires alpn etc, you can use this for testing: > openssl s_client -connect 24.164.77.58:443 -alpn xmpp-client -servername burtrum.org

  34. dwd

    moparisthebest, What was the reason Host Meta 2 got rejected by Council?

  35. singpolyma

    dwd: i suggested it be done as an edit to the existing xep

  36. dwd

    Ah, XEP-0156?

  37. moparisthebest

    singpolyma: I heard back from stpeter, he'd prefer it be a new XEP, I'll officially respond on the mailing list tonight with that and also respond to dwd and MSavoritias (fae,ve) 's messages, apologies for delay

  38. dwd

    No worries on my part. I have an I-D sketched out for SVCB record usage with XMPP. I'm doing a test implementation (or, perhaps, more than one), but I was thinking I might get some early feedback on it from standards@ and/or council@ before I submit it.

  39. singpolyma

    I suggest to just stick to SRV honestly

  40. moparisthebest

    I don't want to get into it again here but if srv supported any of this I'd agree, but it doesn't, so not an option

  41. singpolyma

    Still disagree πŸ™‚

  42. moparisthebest

    singpolyma: fair, then I await your alternative proposals :)

  43. moparisthebest

    dwd: using raw SVCB records or a new XMPP type defined on top? (Like the HTTPS record?) Sadly I'd consider the second one a non-starter due to how unlikely it is to gain any DNS web panel adoption :'( I'm not even sure if raw SVCB ever will...

  44. dwd

    moparisthebest, Raw SVCB records, with additional SvcParamKeys (which are easy to get sorted).

  45. Zash

    If the argument is that we can't use something that isn't supported everywhere, then not even SRV records are good enough and DNS itself must be replaced by HTTPS and JSON all the way down. I'm not _that_ cynic and don't want to live in that world.

  46. moparisthebest

    I mean it's $current-year and we still get reports of DNS hosts that don't support SRV records, iirc pep. has one for xmpp.rs ?

  47. moparisthebest

    I'm literally saying that yes Zash

  48. Zash

    Do Not Want.

  49. MSavoritias (fae,ve)

    +1 on that

  50. moparisthebest

    I too would like to change the world but alas cannot, and don't find it helpful to continue "well you could use XMPP if..." meanwhile everything else just works

  51. dwd

    moparisthebest, I think it's worth specifying and getting it running; I agree that some DNS web panels won't allow it, but some will, and zone files will do from the outset (albeit with the key8= hack).

  52. dwd

    moparisthebest, On the other hand, enabling websockets as first-class citizens in the XMPP world will allow cheaper cloud hosting constructs.

  53. Zash

    moparisthebest, https://developers.cloudflare.com/1.1.1.1/encryption/dns-over-https/make-api-requests/dns-json/ - figure out how to validate DNSSEC in a web page through this plz :P

  54. MattJ

    Some days I admit I'm tempted to go websocket-only in Snikket :)

  55. MSavoritias (fae,ve)

    we could make also https and websockets the only option in core and depreceate xmpp. I mean we live in the real world /s

  56. dwd

    MSavoritias (fae,ve), The two are not mutually exclusive.

  57. moparisthebest

    websockets? That's dead, you mean webtransport

  58. MSavoritias (fae,ve)

    well whatever is in fashion in the real world now instead of xmpp

  59. moparisthebest

    (which I've already implemented, just need host meta 2 to spec it)

  60. moparisthebest

    It's not instead of XMPP, XMPP can go over just about anything

  61. moparisthebest

    (the X is for eXtensible, not Xtuck in the past or Xnever able to be deployed in the wild 🀣)

  62. Wirlaburla

    The X is for eXtreme! Rock on!

  63. dwd

    WebTransport would be fine too. And easy to slam into SVCB too.

  64. moparisthebest

    So yes, imho XMPP should be able to be used seamlessly over whatever is in fashion, vs the much worse alternative of using the new thing that can

  65. dwd

    Agreed entirely - and I think that SVCB is probably the right approach.

  66. moparisthebest

    dwd: I'm torn, on one hand, would like SVCB to be the end goal, on the other... If it has near 0 chance of ever being the-one-way, vs host-meta-2 that can be the-one-way... Then perhaps it's better not to do at all?

  67. dwd

    Except host-meta-2 is never going to be the-one-way either, as people (particularly in anything even vaguely latency-sensitive) will want to use SRV.

  68. singpolyma

    > WebTransport would be fine too. And easy to slam into SVCB too. Also easy to do with SRV πŸ™‚

  69. moparisthebest

    impossible to do with SRV, as is ECH (which is absolutely vital imho)

  70. singpolyma

    I'm not fully against SVCB if there does turn out to be a use case of coure

  71. dwd

    singpolyma, How would you do any web binding with SRV?

  72. singpolyma

    moparisthebest: WebTransport is neither impossible nor difficult to do with SRV I don't get this fud

  73. moparisthebest

    dwd: what latency?

  74. singpolyma

    dwd: it's a hostname and a port number. This is what SRV provides so it's a great math

  75. singpolyma

    dwd: it's a hostname and a port number. This is what SRV provides so it's a great match

  76. dwd

    moparisthebest, With host-meta-2 (or XEP-0156), the initiator needs to do a full HTTP round-trip.

  77. dwd

    singpolyma, web bindings need a path.

  78. singpolyma

    > singpolyma, web bindings need a path. No

  79. moparisthebest

    > moparisthebest, With host-meta-2 (or XEP-0156), the initiator needs to do a full HTTP round-trip. Right, vs 15 or 20 DNS round trips?

  80. dwd

    singpolyma, Why not?

  81. moparisthebest

    Keep in mind DNS is over TLS these days too

  82. singpolyma

    If you want a path at the protocol level for whatever reason then put the path to use in the spec

  83. moparisthebest

    I think it's the same in the end

  84. dwd

    moparisthebest, One, with SVCB. Two if the resolver is being shirty and not putting in the Additional Records.

  85. dwd

    singpolyma, Well, sure, but we haven't, and it's *way* too late now.

  86. singpolyma

    I don't think that's useful or needed beyond / but if people love /.well-known/xmpp/c2s insterd for whatever reason they can spec that

  87. dwd

    singpolyma, You're aware of both host-meta-2 and XEP-0156?

  88. singpolyma

    There's no spec for WT yet so nothing is too late πŸ™‚

  89. singpolyma

    > singpolyma, You're aware of both host-meta-2 and XEP-0156? Yes

  90. dwd

    singpolyma, Sure, but there's also WebSockets and BOSH.

  91. dwd

    singpolyma, Neither have fixed paths.

  92. singpolyma

    > singpolyma, Sure, but there's also WebSockets and BOSH. There aren't xmpp though. We can deprecate them now that WT exists

  93. singpolyma

    Websockets and bosh were fine hacks for one offs and the best we could do at the time

  94. dwd

    singpolyma, What do you mean they're not XMPP? I'm talking aout the bindings of XMPP to those transports.

  95. dwd

    singpolyma, Also, WT doesn't exist. We have no binding, the spec is still in draft, and one of the drivers for me is being able to handle much cheaper/simpler cloud hosting (think AWS ElasticBeanstalk, or Google App Engine).

  96. singpolyma

    We don't really need any magic binding. It's the same as tcp for us

  97. dwd

    singpolyma, What do you mean by that?

  98. moparisthebest

    singpolyma: Read the rationale for host-meta-2 and respond here plz https://mail.jabber.org/hyperkitty/list/standards@xmpp.org/message/3O4V7VC4C5LAI2W5334EGS7ZDMGFUBBN/ no use repeating the same things in an ephemeral place over and over

  99. singpolyma

    WT is just a handshake and then raw quic. So it's the same as tcp from the pov of an xmpp implementation, just a different network stack for quic instead of tcp

  100. singpolyma

    moparisthebest: you're determined to do it your way and that's fine. But I can't see implementing it ever

  101. moparisthebest

    singpolyma: I'm not, but "just use SRV" isn't helpful as I list tons of reasons that isn't possible, even if we just hard code a path, so if you have serious suggestions great, otherwise I don't know what else to do...

  102. MSavoritias (fae,ve)

    it would actually be interesting to see how many applications want to implement this solution actually

  103. moparisthebest

    dwd: haha I reminded myself, as I wrote in the rationale there, ECH requires DNS over TLS or HTTPS so there goes any latency improvements right?

  104. moparisthebest

    > it would actually be interesting to see how many applications want to implement this solution actually This is literally what the XEP process is for, assign a number, running code and consensus wins

  105. moparisthebest

    The alternative is not assigning a number and running code and consensus still wins, that's just less than ideal

  106. dwd

    moparisthebest, I didn't think that was an actual requirement, just a matter of how it actually works for HTTPS currently. One of SVCB's goals was to provide the ECH keying material earlier, to avoid the limitations.

  107. MSavoritias (fae,ve)

    of course. i am just wondering if this "realistic" solutions ends up not being implemented :)

  108. moparisthebest

    dwd: I don't think you want to grab that in the clear though, that defeats the purpose of ECH all together no?

  109. moparisthebest

    I would certainly put that in the spec

  110. moparisthebest

    MSavoritias (fae,ve), singpolyma: again, please provide an alternative, any alternative, even only for ECH if you wish to simplify it (but keep in mind we absolutely need SNI, alpn, probably path, and ideally pinned keys too)

  111. dwd

    moparisthebest, Or maybe not? crypto.cloudflare.com. 300 IN HTTPS 1 . alpn="http/1.1,h2" ipv4hint=162.159.137.85,162.159.138.85 ech=AEX+DQBBQAAgACA4kEeWddw0qWTCm1P+KbW9nYYfHvhJCwXIPviIL4srLQAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA= ipv6hint=2606:4700:7::a29f:8955,2606:4700:7::a29f:8a55

  112. dwd

    moparisthebest, So yeah, I think ech via SVCB is an option.

  113. moparisthebest

    dwd: what do you mean?

  114. moparisthebest

    clients will never fetch and use ech over cleartext DNS quite by design, XMPP clients should be no different

  115. dwd

    Well, mostly for the domain name rather than the keying material, I thought. But DoT is a thing, and possibly an irrelevant one inside cloud hosting environments.

  116. moparisthebest

    DoT and DoH (and hey we have DoX ;))

  117. dwd

    Yes, DoT/DoH could both be useful depending on the initiator; I'd assume that a server would either use DoT or plaintext depending, and a client might always use DoH (but possibly via the OS).

  118. dwd

    moparisthebest, Yeah, checking, esni-17 only mentions encrypted DNS once in 10.6. Also then goes off on one about CRL/OCSP etc.

  119. moparisthebest

    http2 doesn't technically by spec require TLS either, yet 100% of clients in the wild do

  120. moparisthebest

    ECH is even more important because there's a real reason not to do it over plaintext

  121. dwd

    Well... I'd argue that in a server setting, where the server is obtaining DNS from a cloud provider, the only attacker likely to be able to read unencrypted DNS is the cloud provider.

  122. dwd

    Also I wouldn't entirely hold your breath on HTTP/1 requiring TLS. Cloud provdiers tend to strip TLS at the load balancer, so the next hop is plaintext - but currently, I think always HTTP/1.1 (so no WebTransport yet).

  123. moparisthebest

    > Well... I'd argue that in a server setting, where the server is obtaining DNS from a cloud provider, the only attacker likely to be able to read unencrypted DNS is the cloud provider. Which is unacceptable (for servers in the public federated XMPP network, the only one I care about; private deployments as always can do what they want)

  124. moparisthebest

    The cloud provider has no business getting domains being federated with in plaintext

  125. singpolyma

    > MSavoritias (fae,ve), singpolyma: again, please provide an alternative, any alternative, even only for ECH if you wish to simplify it (but keep in mind we absolutely need SNI, alpn, probably path, and ideally pinned keys too) I mean this is exactly why we're at cross purposes on this. I consider puttting in SNI and path to be anti patterns. ALPN I don't love but isn't that just a fixed string we already know anyway?

  126. Zash

    array IIRC

  127. Zash

    > ALPN array IIRC

  128. dwd

    singpolyma, You don't know the ALPN values, and there can be multiple - it's "xmpp-client" for the XEP-0368, but "http/1.1", "h2", or "h3" for the web bindings.

  129. dwd

    singpolyma, Also, needing the path is just a fact, I'm afraid. DoH needs one as well, as you might note from RFC 9641.

  130. singpolyma

    Shouldn't it always be xmpp-client ?

  131. singpolyma

    Anything that needs path is a non starter from my PoV and not a real solution

  132. moparisthebest

    > Shouldn't it always be xmpp-client ? maybe, until xmpp2-client perhaps

  133. moparisthebest

    Still need ECH and SNI value though

  134. dwd

    moparisthebest, Well, no, a web binding will always have a HTTP-related ALPN.

  135. moparisthebest

    Ah right dwd , webtransport is h3

  136. moparisthebest

    Thanks!

  137. dwd

    singpolyma, You might prefer there not to be paths for web bindings, but there are, and no amount of wishing will make them go away.

  138. dwd

    moparisthebest, WebTransport can be "h2" as well, I think.

  139. moparisthebest

    Hmm I didn't think so...

  140. singpolyma

    > singpolyma, You might prefer there not to be paths for web bindings, but there are, and no amount of wishing will make them go away. I don't understand this logic at all. We write the specs *and* the code we can do whatever we want

  141. dwd

    singpolyma, We don't write all the code, and we certainly can't control what's already been written.

  142. singpolyma

    Well, what's already been written isn't really important when we're talking about brand new things :)

  143. singpolyma

    of course old things will keep working however they work today

  144. dwd

    singpolyma, So you're uninterested in backwards compatibility. Well, that's a viewpoint I suppose. Not very practical though.

  145. singpolyma

    there's no backwards compatibility for webtransport or for SRV lookups of websockets if someone wanted to do that. nothing does this today, so there's nothing to be compatible *with*

  146. moparisthebest

    I don't think "paths or not" is very important, because we *have* to have SNI and alpn and ech and any solution that works for them also works for path, I think

  147. singpolyma

    having SNI is just as bad

  148. singpolyma

    and you just had a whole discussion above about how we can't have an alpn that gets detected anyway because it always has to be h3

  149. singpolyma

    AFAICT the only thing worth having that isn't already handled is ECH

  150. moparisthebest

    With current SRV+DNSSEC there are 2 valid SNI values you can send, but you can only send 1, and the server is only configured to handle 1, and you don't know which!!!!

  151. moparisthebest

    Please describe your solution to that SNI problem and also ECH

  152. Zash

    Didn't we just go with always the domain now?

  153. singpolyma

    Zash: I think we should write a XEP overriding the RFC which says that, IMO

  154. moparisthebest

    Zash: why? With DNSSEC you'll accept a cert with a different name

  155. singpolyma

    otherwise we have to go with the RFC but no one is actually doing that

  156. Zash

    If someone is in an IETF mood then a SNI2 that, like ALPN, carries an array would be handy.

  157. moparisthebest

    > If someone is in an IETF mood then a SNI2 that, like ALPN, carries an array would be handy. That's SVCB or maybe HTTPS, I don't remember

  158. Zash

    moparisthebest, in theory, but not in practice, so that's out

  159. Zash

    No

  160. dwd

    I think SNI is "always the domain you wanted", but the certificate it returns can be validated against multiple names.

  161. Zash

    a SNI version that carries an array *in TLS wireprotocol itself*

  162. singpolyma

    If you use DANE you ignore the name in the cert. If you don't use DANE then you need the name in the cert to match the service name. Neither of these is strictly related to SNI

  163. dwd

    That is, SNI and certificate validation names are different.

  164. dwd

    singpolyma, That's a gross simplification.

  165. moparisthebest

    Zash: ah got it

  166. Zash

    If the client tells the server which names(plural) it's willing to validate a cert against, it can make a better decision than it can now

  167. Zash

    So if it would trust a DNSSEC-secured SRV target, it could include that + the xmpp domain name

  168. moparisthebest

    singpolyma: servers are configured to return cert X for SNI Y, it doesn't matter what you'll accept, you need to know the Y they want

  169. Zash

    now it can't so we can't do that

  170. dwd

    Zash, I think that's true, but not a matter of SNI being an array - you still want the same service name.

  171. Zash

    dwd, semantics?

  172. Zash

    I'd be fine with an Alternative Identifier Somethingsomething extension

  173. Zash

    you're sending a Host header or <stream to=> anyway

  174. singpolyma

    SNI picks which cert you want to be given back. So for us I think we should spec it to always be the service name, even though the RFC implies we might not choose that

  175. dwd

    singpolyma, Where does the RFC suggest the SNI to use?

  176. Zash

    which "the RFC" ?

  177. singpolyma

    the dane srv rfc

  178. moparisthebest

    singpolyma: you keep coming up with reasons we might not need this or that, but none of it matters, because we need ECH, and whatever we use for ECH can be used for SNI, alpn, path etc etc

  179. dwd

    singpolyma, Those are two different RFCs.

  180. moparisthebest

    So let's just come up with a ECH solution first :)

  181. singpolyma

    moparisthebest: even if it can be (which it might not be able to, depending on the solution we use) it think it would be bad to have the spec alllow those things

  182. dwd

    singpolyma, Wait, are you meaning RFC 7673?

  183. singpolyma

    yes, I think that's it

  184. singpolyma

    yup

  185. dwd

    singpolyma, OK, then you're incorrect because it says "The service domain name is still the preferred name for TLS SNI"

  186. moparisthebest

    You notice how https specifies alpn to handle different wire protocol versions of http ? Why isn't this helpful in XMPP exactly?

  187. Zash

    You notice how things creep out of the base protocol and into TLS, and then further into DNS? :)

  188. dwd

    It's *always* DNS.

  189. moparisthebest

    Some people seem to want a xmpp-exi for example (not me though)

  190. singpolyma

    dwd: hmm, I do see that part now. I've read this RFC so many times and had so many discussions about this issue. But if it actually says the right thing to begin with why is it even a question

  191. singpolyma goes to read the whole thing again

  192. moparisthebest

    xmpp2-stanzas-are-framed-now I'd be for this one

  193. dwd

    moparisthebest, Oh gosh yes.

  194. moparisthebest

    So we've agreed we must have discoverable alpn then 🀣

  195. dwd

    moparisthebest, WebSocket level framing even, is so much nicer to work with.

  196. moparisthebest

    Other than the first and last stanza being bastardized, fully agreed

  197. Zash

    Where did DNA go? It had some DNSSEC+XMPP stuff but I can't find the final RFC right now

  198. dwd

    moparisthebest, <open>? Yeah, I like that actually, just don't tell anyone.

  199. Zash

    dwd, :O

  200. dwd

    Zash, xmpp-dna? I think it expired and died.

  201. Zash

    dwd, I think it got turned into an RFC with a different name that I never remember, but I could be wrong

  202. moparisthebest

    I just want 16 bits to tell me how many bytes the next stanza is, before every stanza, pretty please

  203. dwd

    Zash, https://datatracker.ietf.org/doc/html/rfc7712

  204. Zash

    and I think xmpp-ws shouldn't have done the <open> thing, or maybe specified a variant that's just xmpp-tcp with a header

  205. dwd

    Zash, Datatracker is your friend.

  206. Zash

    ah, thanks

  207. moparisthebest

    fwiw webtransport is not framed at all

  208. singpolyma

    later on it says > Clients that do not support this specification will indicate a preference for the service domain name, while clients that support this specification will indicate the target server hostname. which seems to contradict > The service domain name is still the preferred name for TLS SNI

  209. dwd

    moparisthebest, The thing is, yeah, prefixed length would be nice (WS gives that inherently), but what else could we have?

  210. moparisthebest

    What do you mean?

  211. Zash

    bad idea, do not implement: put length prefixes as plain text before each stanza, like chunked http

  212. Zash

    (pretty sure prosody and probably other servers just ignore it, like whitespace keepalives)

  213. dwd

    It's not like parsing an ASCII number is going to be the performance bottleneck.

  214. moparisthebest

    And length prefix the text length prefix?

  215. dwd

    But man that would allow some sneaky attacks with stanza smuggling.

  216. moparisthebest

    Otherwise how long is it in bytes

  217. dwd

    moparisthebest, Careful, you're going to go full BER.

  218. dwd

    Never go full BER.

  219. moparisthebest

    But yes, stanza smuggling is one reason this needs negotiated beforehand, thankfully we have alpn for this

  220. flow

    > moparisthebest> I just want 16 bits to tell me how many bytes the next stanza is, before every stanza, pretty please

  221. flow

    may I interest you in imap?

  222. Zash

    imap, the thing that's being replaced by json over https?

  223. flow

    everything gets eventually replaced

  224. Holger

    > I just want 16 bits to tell me how many bytes the next stanza is netstrings!

  225. Holger

    netstanzas.

  226. moparisthebest

    flow: alpn of xmpp-imap you say? πŸ€”

  227. Zash

    weren't netstrings ascii?

  228. Holger

    Probably.

  229. flow

    moparisthebest, don't you do an AI on me!

  230. dwd

    IMAP certainly prefixed with ASCII.

  231. moparisthebest

    I've yet to have the pleasure of looking at imap protocol

  232. flow

    dwd, past tense? is imap so dead?

  233. dwd

    Although if we were going to go that route, I'd go ACAP from the outset. Better design, ironed out a lot of the weird bits of IMAP syntax.

  234. dwd

    flow, Well, it was designed a looooong time ago.

  235. flow

    can't be, I still remeber it being the new hot thing after POP

  236. moparisthebest

    flow: quick how old is XMPP ;)

  237. flow

    from the top of my head: 1999ish

  238. dwd

    flow, Designed in 1986. Literals might not have come in until IMAP2 in 1988.

  239. dwd

    flow, And yes, Jabber is 1999, XMPP was published in 2011.

  240. Holger

    Our protocol is just 3 years older than Matrix!

  241. MSavoritias (fae,ve)

    wait before 2011 it was jabber

  242. MSavoritias (fae,ve)

    oO

  243. dwd

    Oh, apparently 1998. Server published on 4th Jan 1999.

  244. Zash

    unless jeremie worked *really fast* jan 1-4 :)

  245. dwd

    MSavoritias (fae,ve), Well, the shift to XMPP was before that; and the XSF was renamed afterwards I *think*.

  246. MSavoritias (fae,ve)

    it was always xmpp to me. never used jabber in my life. then again i have only been around here for like 3ish years

  247. Zash

    https://xmpp.org/rfcs/rfc3920.html was published in 2004

  248. dwd

    Zash, Oh, yes. I grabbed the date off Wikipedia and I picked the wrong one. :-)

  249. dwd

    RFC 6120 was 2001.

  250. dwd

    2011, rather.

  251. dwd

    Can't type now.

  252. moparisthebest

    > it was always xmpp to me. never used jabber in my life. then again i have only been around here for like 3ish years Same, jabber is that strange proprietary Cisco business thing? Google says so, must be true

  253. Zash

    Hmm, October will be 20 years since rfc3920, the True birth of XMPP?

  254. dwd

    Cisco bought Jabber Inc, which caused the JSF to rename itself out of fear.

  255. Zash

    Jabber Inc, the Element of its day?

  256. MSavoritias (fae,ve)

    jsf sounds harder to pronounce anyway

  257. dwd

    MSavoritias (fae,ve), Talk to some of the people who've been involved a long time, and they talk about JEPs.

  258. MSavoritias (fae,ve)

    yeah i have heard that one. shows how long the person has been involved :D

  259. dwd

    Zash, Not really, Cisco paid well for it. Or Webex did. I can't even recall if Webex was already bought by Cisco by then or not.

  260. Zash

    Companies buying companies all the way down eh

  261. dwd

    Indeed.

  262. Zash

    And can someone tell me if it's LuaSec or OpenSSL that's being silly and not telling me the selected ALPN at the point in time when I have to choose which SNI certificate to return?

  263. dwd

    I've yet to play with ALPN at all. Metre doesn't (yet) support it.

  264. Zash

    Prosody can use it for protocol multiplexing. Prosody can do protocol multiplexing without it too, so it's pretty useless and only good for avoiding guessing of protocol based on string matching...

  265. Zash

    XEP-0363, is this you <https://slashdot.org/comments.pl?sid=15607&cid=2048735> ?

  266. Zash

    Okay, SNI callback happens before ALPN callback. Thanks OpenSSL

  267. moparisthebest

    > Okay, SNI callback happens before ALPN callback. Thanks OpenSSL Zash: I mean, I totally believe it (cause OpenSSL), but that's insane because both come together in the ClientHello

  268. moparisthebest

    easy(tm) solution: switch to rustls 🧌

  269. dwd

    OK, so Metre sets the SNI but ignores it inbound.

  270. moparisthebest

    xmpp-proxy currently takes the easy way out by only supporting 1 certificate :) but does set alpn/sni outgoing all ways

  271. dwd

    Zash, Reading this, it looks like you can just try fetching the servername in the ALPN callback. Worst case is a client that sets ALPN but not SNI, so you'd need to handle the error, but otherwise should work OK.

  272. dwd

    Zash, Or the other way around - get the ALPN in the SNI callback.

  273. Fishbowler

    > If it has near 0 chance of ever being the-one-way Very few things have the-one-way, and I don't think XMPP really suits one.

  274. Zash

    dwd, but the SNI callback is the one that selects the certificate to use, and ALPN is not known *at all* at that point, so no way to return a certificate with id-on-srvname, if such a thing wasn't forbidden by the CA/Bal

  275. moparisthebest

    >> If it has near 0 chance of ever being the-one-way > Very few things have the-one-way, and I don't think XMPP really suits one. What other examples have more than 1 way?

  276. pep.

    "moparisthebest> I mean it's $current-year and we still get reports of DNS hosts that don't support SRV records, iirc pep. has one for xmpp.rs ?" I think I miraculously managed to setup SRV with their previous interface. After their overhaul I can't even add TXT, so just ignore them

  277. pep.

    "moparisthebest> Keep in mind DNS is over TLS these days too" I wish, it was, and not over https :x

  278. moparisthebest

    "it's the same picture"

  279. dan.caseley

    > What other examples have more than 1 way? How many ways are there to connect to a mailbox? POP, IMAP, webmail...

  280. moparisthebest

    dan.caseley: I think all those have 0 or 1 way to discover connections though?