XSF Discussion - 2018-01-08

  1. vanitasvitae has left
  2. ralphm has left
  3. ralphm has joined
  4. lskdjf has left
  5. la|r|ma has left
  6. la|r|ma has left
  7. la|r|ma has left
  8. la|r|ma has left
  9. la|r|ma has joined
  10. la|r|ma has left
  11. daniel has left
  12. la|r|ma has left
  13. la|r|ma has left
  14. daniel has joined
  15. la|r|ma has left
  16. moparisthebest has left
  17. moparisthebest has joined
  18. la|r|ma has left
  19. la|r|ma has left
  20. la|r|ma has left
  21. la|r|ma has left
  22. la|r|ma has left
  23. la|r|ma has left
  24. la|r|ma has left
  25. jere has joined
  26. lumi has left
  27. la|r|ma has joined
  28. la|r|ma has left
  29. la|r|ma has left
  30. la|r|ma has left
  31. moparisthebest has left
  32. moparisthebest has joined
  33. la|r|ma has left
  34. la|r|ma has left
  35. efrit has joined
  36. la|r|ma has left
  37. jere has left
  38. jere has joined
  39. la|r|ma has left
  40. la|r|ma has left
  41. la|r|ma has left
  42. winfried has left
  43. winfried has joined
  44. la|r|ma has left
  45. SamWhited has joined
  46. winfried has joined
  47. winfried has joined
  48. la|r|ma has left
  49. @Alacer has left
  50. waqas has left
  51. @Alacer has joined
  52. la|r|ma has left
  53. la|r|ma has left
  54. lskdjf has joined
  55. SamWhited has left
  56. @Alacer has left
  57. @Alacer has joined
  58. lskdjf has joined
  59. hannes has left
  60. hannes has joined
  61. efrit has left
  62. efrit has joined
  63. daniel has left
  64. daniel has joined
  65. la|r|ma has joined
  66. daniel has left
  67. efrit has left
  68. winfried has left
  69. daniel has joined
  70. vanitasvitae has joined
  71. daniel has left
  72. zinid has left
  73. daniel has joined
  74. zinid has joined
  75. hannes has left
  76. hannes has joined
  77. Tobias has left
  78. Tobias has joined
  79. daniel has left
  80. daniel has joined
  81. moparisthebest has left
  82. moparisthebest has left
  83. daniel has left
  84. moparisthebest has joined
  85. moparisthebest has left
  86. daniel has joined
  87. daniel has left
  88. winfried has joined
  89. hannes has left
  90. goffi has joined
  91. ralphm has joined
  92. ralphm has left
  93. daniel has joined
  94. daniel has left
  95. ralphm has joined
  96. suzyo has joined
  97. Tobias has left
  98. Tobias has joined
  99. ralphm has left
  100. Guus has joined
  101. daniel has joined
  102. ralphm has joined
  103. daniel has left
  104. daniel has joined
  105. daniel has left
  106. daniel has joined
  107. Guus has left
  108. Guus has joined
  109. daniel has left
  110. daniel has joined
  111. Guus has left
  112. daniel has left
  113. Kev has left
  114. daniel has joined
  115. suzyo has joined
  116. blabla has left
  117. ralphm has joined
  118. ralphm has left
  119. Steve Kille has left
  120. blabla has left
  121. Steve Kille has left
  122. Martin has joined
  123. Steve Kille has joined
  124. @Alacer has left
  125. @Alacer has joined
  126. xnyhps has joined
  127. Guus has joined
  128. Steve Kille has left
  129. daniel has left
  130. daniel has joined
  131. ralphm has left
  132. Alex has joined
  133. Ge0rG has joined
  134. hannes has joined
  135. zinid has left
  136. hannes has left
  137. hannes has joined
  138. ralphm has joined
  139. ralphm has joined
  140. hannes has left
  141. hannes has joined
  142. Martin has left
  143. hannes has left
  144. hannes has joined
  145. ralphm has joined
  146. ralphm has left
  147. tux has joined
  148. tux has joined
  149. lumi has joined
  150. tux has joined
  151. ralphm has joined
  152. vanitasvitae has joined
  153. ralphm has left
  154. vanitasvitae has left
  155. vanitasvitae has joined
  156. vanitasvitae has left
  157. pep. has joined
  158. Alex has left
  159. ralphm has joined
  160. hannes has left
  161. hannes has joined
  162. Alex has joined
  163. ralphm has joined
  164. Alex has left
  165. lskdjf has joined
  166. la|r|ma has joined
  167. jonasw has left
  168. ralphm has joined
  169. moparisthebest has joined
  170. moparisthebest has joined
  171. ralphm has joined
  172. Steve Kille has left
  173. marc has joined
  174. zinid has left
  175. ralphm has joined
  176. ralphm has left
  177. daniel has left
  178. daniel has joined
  179. Flow has left
  180. moparisthebest has joined
  181. moparisthebest has joined
  182. valo has joined
  183. daniel has left
  184. valo has joined
  185. daniel has joined
  186. Guus has left
  187. vanitasvitae has joined
  188. hannes has left
  189. hannes has joined
  190. ralphm has joined
  191. @Alacer has left
  192. @Alacer has joined
  193. @Alacer has left
  194. @Alacer has joined
  195. @Alacer has left
  196. @Alacer has joined
  197. Guus has joined
  198. la|r|ma has left
  199. suzyo has joined
  200. hannes has left
  201. hannes has joined
  202. daniel has left
  203. daniel has joined
  204. hannes has left
  205. hannes has joined
  206. uc has left
  207. uc has joined
  208. ralphm has joined
  209. suzyo has joined
  210. Kev has left
  211. Kev has joined
  212. daniel has left
  213. daniel has joined
  214. ralphm has left
  215. uc has joined
  216. uc has joined
  217. ralphm has joined
  218. @Alacer has left
  219. @Alacer has joined
  220. uc has joined
  221. efrit has joined
  222. uc has joined
  223. Dave Cridland has joined
  224. Dave Cridland Afternoon, all.
  225. SouL Greetings!
  226. Dave Cridland Just submitted one Internet Draft, plus two ProtoXEPs, covering adding TOTP-based 2FA to XMPP.
  227. Dave Cridland edhelas, You might be interested in that, as I recall.
  228. edhelas link ?
  229. jonasw two(!) protoxeps
  230. jonasw you want me to fail my exams!!!k
  231. jonasw I may take care of them tonight
  232. Dave Cridland jonasw, No problem.
  233. Dave Cridland jonasw, As in, no rush - not that your exams aren't a problem.
  234. jonasw I understood, and also I was joking :)
  235. suzyo has joined
  236. Dave Cridland edhelas, https://github.com/surevine/xeps/blob/totp-2fa/inbox/totp-2fa.xml if you can deal with an unrendered version. But I'm seeing a build error in that - whoops. ALso I'm a bit light on example flows, which is poor given I've implemented this bit.
  237. jjrh has left
  238. Dave Cridland edhelas, The Internet Draft is here: https://datatracker.ietf.org/doc/draft-cridland-kitten-clientkey/
  239. Dave Cridland edhelas, That basically covers a SASL mechanism designed to cope with the fact we don't want to ask for TOTP codes every time, and also don't want to weaken security by not doing so.
  240. Dave Cridland edhelas, It demands a few supporting functions from the containing protocol, which is the other ProtoXEP.
  241. edhelas okay good
  242. edhelas will have a look at it asap
  243. Ge0rG Dave Cridland: how often is it supposed to ask for TOTP veriifcation?
  244. Dave Cridland Ge0rG, Without the CLIENT-KEY mechanism? Every time.
  245. Ge0rG Dave Cridland: this question is generally interesting to me in the context of long-living TCP sessions, but also for 0198 and ISR
  246. Dave Cridland Ge0rG, That would, of course, be nuts.
  247. Ge0rG Dave Cridland: and with client key?
  248. Dave Cridland Ge0rG, With CLIENT-KEY, it wouldn't. But CLIENT-KEY has expiry and things built in, to force users to reauthenticate.
  249. jjrh has left
  250. jonasw Dave Cridland, Builds/xeps/inbox/totp-2fa.xml: not well-formed (invalid token): line 99, column 61
  251. daniel has left
  252. daniel has joined
  253. Dave Cridland jonasw, Yeah, the ABNF. On it...
  254. Ge0rG Dave Cridland: will CLIENT-KEY expiry close the session, or require an in-session reauth?
  255. Dave Cridland Neither.
  256. jere has joined
  257. Ge0rG So if I have a good network, I can stay logged in forever?
  258. jonasw at some point, the servers certificate will expire and your client will of course disconnect you :)
  259. Dave Cridland Ge0rG, Sure. I imagine if a server admin thought this was a problem they could put in a session expiry.
  260. Ge0rG jonasw: I LOLed.
  261. jonasw sleekxmpp actually does that.
  262. Kev Presumably if there is an issue with authentication of long-lived sessions, this goes beyond the tokens, and would apply to all sessions.
  263. Kev Seems orthogonal to this.
  264. ralphm has joined
  265. Dave Cridland jonasw, Incorrectly, I'd suggest. The certificate defines how long the identity assertion is warranted for, not how long the identity might last.
  266. jjrh has left
  267. Dave Cridland jonasw, Travis is back doing its magic on an update.
  268. jonasw Dave Cridland, not sure. If I actually managed to steal a certificate, long-running sessions would fall for me longer than needed.
  269. Dave Cridland jonasw, Quite possibly. But that's not what the certificate expiry is for.
  270. jonasw so it would be more reasonable to periodically check CRLs, fair enough. But once the certificate is expired, you don’t have anything to check for in the CRL anymore.
  271. jonasw ah okay, but you could also assume that the identity was then correctly asserted when you connected and don’t need to care anymore.
  272. jonasw Dave Cridland, built for website in progress, ETA 2h
  273. jjrh has left
  274. mathieuii Dave Cridland, maybe the namespace would be better as urn:xmpp:totp:0? "mfa" is a bit broader than TOTP
  275. Dave Cridland has left
  276. uc has left
  277. uc has joined
  278. jonasw Steve Kille, for the next time, please note that you’re in the wrong month with your revision dates (2018-02 vs. 2018-01). I fixed it this time :)
  279. Steve Kille oopps
  280. Steve Kille and thanks
  281. jonasw build in progress, ETA ≤ 2h
  282. mathieuii one of my concerns is that most services offering TOTP have "recovery codes" the user can use when they lose their secret
  283. jjrh has left
  284. Ge0rG mathieuii: is that a sentiment about lack of security of 2FA implementations?
  285. mathieuii not security, rather improved security leading to account locking
  286. Ge0rG it should be really hard but not impossible to recover from a 2FA loss
  287. mathieuii yes
  288. mathieuii well, currently there’s no standard for password recovery either, so that’s consistent at least
  289. Ge0rG I'm still interested in specifying how long a session is bound to be valid, and if it should be legal to resume a session from a different TCP connection by means of ISR+0198.
  290. jonasw isn’t that the whole idea of ISR+0198?
  291. Ge0rG jonasw: yes
  292. Ge0rG jonasw: but consider a pre-ISR pre-CLIENT-KEY world, where the user enters a TOTP token value on each login.
  293. Ge0rG how long should that authenticated session be considered valid? Until the expiry of the server SSL cert?
  294. Flow has joined
  295. Ge0rG Hi Flow! Were just talking about you ;)
  296. Flow what a coincidence :)
  297. MattJ It's similar to the question of whether s2s connections should close when the cert that was used to authenticate them expires
  298. Ge0rG I tend to agree with Kev that it's somewhat orthogonal to SSL cert lifetime, though.
  299. Ge0rG The question still remains, how long and under which conditions a session should be considered valid.
  300. Ge0rG TLS session reuse also comes to mind in this context.
  301. Ge0rG But I'm not very inclined to outsource the reauth of a layer 7 client session to TLS.
  302. Ge0rG I assume this is related to the identity of the client (device|application), and the amount of state an attacker has to extract to prove he's actually that entity.
  303. Zash Do you stop being you when your cert expires?
  304. mathieuii yes
  305. Ge0rG Zash: you can't know for sure.
  306. ralphm has joined
  307. Dave Cridland mathieuii, Oh, we did account unlocking too. Do we want a XEP on it? We did that as a SASL mechanism based around emailed codes.
  308. Ge0rG Why must everything be a SASL mechanism?
  309. Dave Cridland Ge0rG, Because it's an authentication, and that's where authentications live in XMPP.
  310. Ge0rG So it requires to re-login to enter the unlock code?
  311. Dave Cridland Ge0rG, No, an unlock code *is* an authentication.
  312. Dave Cridland has left
  313. Dave Cridland has left
  314. Ge0rG Dave Cridland: oh, maybe I have a different understanding of that term then.
  315. Dave Cridland Ge0rG, Well, let me put it this way. After entering an unlock code, the system then trusts you sufficiently that it'll let you reset passwords, reconfigure TOTP, etc. That means presumably it trusts that you are who you claim to be, which means an authentication must have occured by definition.
  316. Ge0rG Dave Cridland: I was thinking about "unlock" in the sense that your account gains additional permissions after verifying that you have read access to that email address.
  317. Ge0rG Dave Cridland: what you are describing sounds like a password|credentials reset mechanism, which of course _is_ an authentication
  318. Dave Cridland Ge0rG, Ah, I see. No, I was meaning the codes to unlock/recover an account when the TOTP is lost.
  319. Ge0rG so maybe "account recovery" would be a better term, then
  320. Dave Cridland Ge0rG, Yeah, probably.
  321. Ge0rG marc and I are working on a quick&dirty solution to a similar problem, where you have an initial token that you use to complete an account registration, and our plan was to stuff it into an additional IBR element.
  322. Ge0rG Though I must admit I don't particularly like that approach.
  323. Ge0rG Technically speaking, the account already exists with a given user name but without a password, and that approach allows a client to re-use the IBR flow to set a user-defined password.
  324. Ge0rG This is pretty similar to account recovery, though.
  325. marc Ge0rG, didn't follow the discussion but the account doesn't exists in my approach
  326. Ge0rG marc: how do you ensure that nobody else registers the same account?
  327. marc Ge0rG, checking :)
  328. Ge0rG marc: this answer is insufficient.
  329. marc Ge0rG, for user invitation you don't have the problem
  330. marc for account creation the account name is reserved
  331. Holger has left
  332. Ge0rG marc: the easiest way to reserve an account name is to regiser that account, isn't it?
  333. marc Ge0rG, no, because the invitation may expire
  334. marc account creation
  335. Ge0rG Ah, right.
  336. marc Puh, I expected a big discussion :D
  337. marc I should write this down right now...
  338. marc Ge0rG, btw, we still need the ibr=true query parameter, right?
  339. Ge0rG marc: yes
  340. marc okay, good
  341. jonasw marc, how’s your progress on submitting the protoxep?
  342. marc jonasw, what does submitting mean? Official submitting or publishing it on my web server?
  343. jonasw marc, the former
  344. jonasw a PR to the xeps repo
  345. Guus For those that are interested: I've send out the summit / fosdem hotel group discount details and registration form to the summit mailing list.
  346. vanitasvitae has left
  347. marc I don't know how a protoXEP should look like before submitting it
  348. jonasw marc, if it’s implementable, that’s already quite good. basic readability, a set of requirements you want to achieve, a basic motivation and of course a protocol description.
  349. vanitasvitae has joined
  350. vanitasvitae has left
  351. Ge0rG The end is nigh! https://techcrunch.com/2018/01/08/telegram-open-network/
  352. mathieuii "Durov’s idea is to launch an entirely new blockchain" send help
  353. marc jonasw, I need a better motivation and probably some other stuff is missing
  354. marc jonasw, I try to push it to my webserver tomorrow
  355. marc So you guys can look at it, give some feedback before pushing it to xsf repo
  356. Ge0rG marc: I can help you writing some sections. Just give me a git 😜
  357. jonasw I feel that this feedback should happen in official protoxep or even experimental state.
  358. Ge0rG I've submitted the astonishing number of 1 xeps already.
  359. marc jonasw, I don't think so because I expect that there will be some really basic mistakes etc.
  360. jonasw marc, don’t worry about that
  361. marc Ge0rG, will give you a Git tomorrow I think
  362. jonasw this will help ironing out those mistakes. if it is too bad for Experimental status (which I don’t think), you can still refine it
  363. Ge0rG marc: 👍🏽
  364. hannes has joined
  365. ralphm has joined
  366. Dave Cridland has left
  367. Dave Cridland has left
  368. daniel has left
  369. daniel has joined
  370. Dave Cridland jonasw, +1 to that.
  371. Dave Cridland Or more generally, if it's worth working on, it's worth submitting.
  372. zinid Ge0rG, > Durov and his brother Nikolai Durov, a mathematical genius I lol'd. Who wrote this?
  373. Ge0rG zinid: probably a journalistics genius.
  374. ralphm has joined
  375. Dave Cridland Man, that's one seriously transparent Poniz scheme.
  376. Dave Cridland Man, that's one seriously transparent Ponzi scheme.
  377. Dave Cridland "Its proof of stake approach will reach consensus through a variant of the ‘Byzantine Fault Tolerant’ protocol, again increasing speed and efficiency." - erm, BFT algorithms are universally slower than normal consensus algorithms. Pretty sure that normal Bitcoin is BFT as well. Also BFT is a property not a protocol.
  378. zinid of course BFT is slower, especially the one with timeouts
  379. Ge0rG Now stop bashing the Durovs and let's focus on our own ICO! JabberCoin!
  380. daniel has left
  381. daniel has joined
  382. Ge0rG I even have a motto for it already: "The brightest light [or lamp?] in crypto moneys!"
  383. intosi XeptoCoin?
  384. moparisthebest introducing, JabberCoin! (5 minutes later, sued to death by cisco...)
  385. zinid there is already a shitcoin
  386. Ge0rG Oh, right. That trademark thing.
  387. Ge0rG zinid: so we make a JIDcoin
  388. moparisthebest zinid, a ? like only 1 ?
  389. Dave Cridland moparisthebest, The XSF can license us, though.
  390. Ge0rG Dave Cridland: I'm not sure we can have something that starts with "jabber" and is a commercial entity from the XSF.
  391. zinid moparisthebest, https://github.com/shitcoin/shitcoin
  392. Ge0rG From my last reading of the terms, it needs Cisco approval.
  393. Ge0rG ,oO( Initial Github Offering? )
  394. zinid created a bug report: https://github.com/shitcoin/shitcoin/issues/6
  395. moparisthebest zinid, I'd give that coin an award for truth in advertising
  396. Dave Cridland Ge0rG, Yes, you're right.
  397. Ge0rG Dave Cridland: that's almost the only thing stopping me from creating the Jabber Software Foundation. That, and a lack of volunteers.
  398. marc has left
  399. Dave Cridland Ge0rG, If it's non-profit you could.
  400. Ge0rG Dave Cridland: I can't even get people to sign my anti-spam manifesto. How am I supposed to build up a Foundation?
  401. zinid what manifesto?
  402. moparisthebest Starting from the bottom usually
  403. Ge0rG zinid: https://gist.github.com/ge0rg/2e4accf6950821ca45f743fdf587c08e
  404. Dave Cridland has left
  405. Dave Cridland has left
  406. Dave Cridland Ge0rG, With your natural charisma?
  407. zinid not sure what is the goal of the manifesto
  408. zinid to reach a consensus?
  409. Ge0rG zinid: to make a public statement about blocking and shaming abandoned servers.
  410. MattJ To reach a long list of good spam-free servers
  411. moparisthebest zinid: get major server admins to agree?
  412. zinid ok, and what practical implications?
  413. jonasw Ge0rG, where did you even advertise that?
  414. Ge0rG jonasw: the manifesto? I asked some server admins so far
  415. MattJ zinid, if you're not on the list, people may limit/filter/block traffic from your server
  416. moparisthebest jonasw agreed to operate an rbl right? :)
  417. zinid MattJ, nice 🙂
  418. zinid but what if I don't run a public server? I'll be blocked too?
  419. MattJ If you don't originate spam, I doubt it :)
  420. jonasw moparisthebest, I did
  421. Ge0rG XMPP spam is Russian. zinid is Russian. Might get blocked by accident.
  422. jonasw :>
  423. jonasw block ru TLD, be done with spam ;-)
  424. Ge0rG jonasw: no, they are using IBR servers all over the world. Need to block cyrillic letters instead.
  425. jonasw I wasn’t serious anyways
  426. moparisthebest jonasw, re: rbl, someone mentioned not-dns but can you imagine the beefy xmpp server you'd have to host to accept s2s from all other xmpp servers? 😕 vs tiny resources of a dns server, or use cloudflare ...
  427. jonasw moparisthebest, yeah, dns it’ll be
  428. jonasw I’ll also run this on a dedicated machine. I expect some trouble out of it.
  429. Ge0rG jonasw: you should run it on a dedicated uplink then.
  430. jonasw Ge0rG, that’s my ISPs job :>
  431. Ge0rG in a dedicated data center.
  432. Ge0rG on a dedicated Internet.
  433. jonasw they have DDoS-protection
  434. jonasw at least they advertise it
  435. moparisthebest you could just let a big DNS provider take care of it for you
  436. jonasw moparisthebest, thought of that, but I wonder how well updates would work with that
  437. moparisthebest cloudflare, hurricane electric, I'm sure there are other free ones
  438. moparisthebest cloudflare has an API at least
  439. jonasw I don’t like cloudflare
  440. Ge0rG you could run a hidden primary and have some provider run the secondaries.
  441. moparisthebest jonasw, another, yep what Ge0rG said
  442. jonasw Ge0rG, that sounds like a good plan.
  443. daniel has left
  444. daniel has joined
  445. zinid Ge0rG, do you have s2s dialback enabled on yax.im?
  446. jere has joined
  447. moparisthebest jonasw, for my domains I run hidden primary and use these 3 providers (4 dns servers total) for "secondary" https://freedns.afraid.org/secondary/ https://puck.nether.net/dns/dnsinfo https://acc.rollernet.us/dns/secondary.php
  448. moparisthebest only ones I could find that support everything I needed, dnssec and such too
  449. Ge0rG zinid: yes I do
  450. daniel has left
  451. daniel has joined
  452. Ge0rG moparisthebest: do you have stats from them?
  453. Ge0rG is looking for a new secondary for some zones
  454. jonasw Ge0rG, I’ll be happy to :)
  455. moparisthebest Ge0rG, what kind of stats?
  456. jonasw but no guarantees :)
  457. daniel has left
  458. daniel has joined
  459. Ge0rG moparisthebest: reliability, speed of zone propagation, such things.
  460. Ge0rG has been using the freendns dyndns service for some 15 years now
  461. moparisthebest Ge0rG, so 2 of the 3 providers support the push thing so zone propagation is instant
  462. jonasw unfortunately, cloudflare thinks that DNS secondary is an enterprise solution :/
  463. moparisthebest I want to say puck.nether.net is the one that takes up to like 10 minutes
  464. moparisthebest but as to the rest, I've been using them for years and never noticed any of them being down (I run a script hourly to check)
  465. Ge0rG moparisthebest: great!
  466. moparisthebest which, is good enough for me, that's why I have 3 different providers and 4 servers 😛
  467. moparisthebest the likliehood all 3 are ever down seems slim
  468. jonasw anyways, gotta go
  469. daniel has left
  470. daniel has joined
  471. daniel has left
  472. daniel has joined
  473. daniel has left
  474. daniel has joined
  475. Ge0rG Monal. Will create an individual notification for each message in a conversation. Won't delete any if you respond from the PC.
  476. vanitasvitae has joined
  477. ralphm has joined
  478. moparisthebest Ge0rG, this is a good one too (multicast) but no dnssec 😢 https://system-ns.com/services/secondary
  479. daniel has left
  480. daniel has joined
  481. moparisthebest in fact I have a HUGE list of free secondaries that do not do dnssec if you want that I can send that to you somewhere else
  482. Ge0rG moparisthebest: not that I would care about DNSSEC, with the sad .IM situation
  483. moparisthebest yea, what happened with that?
  484. moparisthebest last I heard they said they would add support, which had to have been years ago
  485. Ge0rG moparisthebest: really? Last thing I heard was "not on the agenda"
  486. Dave Cridland has left
  487. Dave Cridland has left
  488. Ge0rG And that was when DLV was still a thing
  489. Alex has joined
  490. moparisthebest I thought someone from here contacted them
  491. Ge0rG moparisthebest: I did
  492. Ge0rG moparisthebest: last time in 2015, "Unfortunately as per our previous correspondence there is still no movement regarding your query."
  493. moparisthebest Currently .im zone does not support DNSSEC, which will eventually make it a more secure and robust. You can help convince .im authorities to support DNSSEC by sending email to the special address dnssec@nic.im.
  494. moparisthebest wonder if that email still exists, also, you should bug them again Ge0rG 😛
  495. Ge0rG I've lost my hope in DNSSEC
  496. moparisthebest nowadays I don't buy domains unless they have full dnssec support 😢
  497. moparisthebest at least all the new ones are required to have it
  498. marc has left
  499. suzyo has joined
  500. lskdjf has joined
  501. daniel has left
  502. efrit has left
  503. marc has left
  504. daniel has joined
  505. Kev has left
  506. vanitasvitae has left
  507. georg has joined
  508. Ge0rG Sigh. Clients that ignore the bookmarked nickname for 300.
  509. Ge0rG And then a gazillion popups from ChatSecure. Looks like it does MUC MAM too, now.
  510. ralphm has joined
  511. vanitasvitae has joined
  512. georg has left
  513. vanitasvitae has left
  514. efrit has joined
  515. vanitasvitae has joined
  516. Ge0rG has joined
  517. suzyo has joined
  518. suzyo has joined
  519. Dave Cridland has left
  520. Dave Cridland has left
  521. daniel has left
  522. daniel has joined
  523. @Alacer has left
  524. blabla has left
  525. Syndace has joined
  526. Syndace has left
  527. Syndace has joined
  528. tux has joined
  529. daniel has left
  530. daniel has joined
  531. Dave Cridland has left
  532. suzyo has joined
  533. suzyo has joined
  534. jere has joined
  535. Kev Ge0rG: I have put XMPP2 onto the Summit agenda. I don't know if you'll be there, but I'll be covering it if you're not.
  536. jere has joined
  537. ralphm has joined
  538. Ge0rG Kev: I think the most probable outcome is me tele-participating.
  539. Ge0rG Even though I always only get 30% through WebEx :(
  540. Ge0rG Kev: have you written down any proto-XEP yet?
  541. Kev I was hoping to get the Informational thing submitted before the summit, but that's looking very tight now. We'll see.
  542. Kev Right, I was just typing that :)
  543. Ge0rG Kev: Also, I think last time we limited the scope from XMPP2 down to message routing 2
  544. Kev I think we need to cover more than just message routing 2, to be able to advance various things.
  545. daniel has left
  546. daniel has joined
  547. Ge0rG Kev: various things are good, right?
  548. Kev I don't know which of the possible meanings of that you intend.
  549. Ge0rG Kev: I hope I can take the time to actually do my presentation; maybe that would be a good prequel to your XMPP2?
  550. Ge0rG Kev: I'm not quite sure what you think needs solving beyond message routing in XMPP2, so I've lost track of the scope of our discussion now.
  551. Kev Multi-device sync.
  552. Kev Of which message routing is a subset, I think.
  553. Kev I think bind2/sasl2 are part of this too, although maybe they don't currently need discussion.
  554. Ge0rG Kev: I'd consider multi-device sync as part of the message routing problem.
  555. Kev No, definitely the other way around :)
  556. Kev Because sync involves both history fetching and read-state synchronising, neither of which is routing :)
  557. Ge0rG it's routing to the archive and from the archive ;)
  558. Ge0rG but it's all part of the same problem, and "multi-device sync" is as good a name as anything.
  559. Kev It also *might* include highlighting notifications potentially.
  560. Kev Although that is strictly distinct and can be worked on separately.
  561. Ge0rG Kev: there is some overlap. And some other overlap with push.
  562. Kev There is *huge* overlap with push.
  563. Ge0rG Except when E2EE is involved.
  564. Kev Push is essentially just one instance of highlight/notifications.
  565. Ge0rG Well, you might be right on that one.
  566. moparisthebest Can xmpp 2 ditch STARTLS also?
  567. Kev I think that's roughly orthogonal, isn't it?
  568. Ge0rG Kev: except in the current ISR spec
  569. Ge0rG where there is a `location` pointer to a direct-TLS server.
  570. moparisthebest Kev: well if the goal is to make things quicker no
  571. Kev moparisthebest: That isn't the goal of this in general, no.
  572. moparisthebest One srv query is better than two, plus TLS goodies like 0rtt , fast start etc etc
  573. moparisthebest Or if the goal is to reduce legacy at all
  574. Kev Yes, not arguing that going back to 'xmpps' isn't sensible, but I don't see that as part of the same problem.
  575. Kev No, reducing legacy isn't an aim in itself.
  576. moparisthebest Well like Ge0rG said isr requires direct TLS, if you don't drop STARTLS all new servers need to support both
  577. zinid everyone went back to xmpps already, after configuring direct-tls on my server, all my clients automatically switched on it (dino and conversations)
  578. moparisthebest Seems like a small beneficial change to me
  579. bear has left
  580. moparisthebest And so I hear gajim 1.0 beta zinid
  581. zinid all the more so
  582. Guus has left
  583. Kev moparisthebest: We can't drop STARTTLS for as long as we have 6120. Which I've no interest in replacing.
  584. bear has joined
  585. moparisthebest ah I thought this was the push to new RFC
  586. moparisthebest the new routing rules don't conflict?
  587. tux has joined
  588. zinid 6120 is okayish, it's 6121 which should be replaced, IMO
  589. zinid has left
  590. Kev I don't think there's any fundamental issues in 6120. I was just noting that 6120 requires starttls, so things need to keep implementing it.
  591. Kev And yes, chunks of 6121 needs overriding.
  592. jjrh has left
  593. Guus has left
  594. Dave Cridland has left
  595. moparisthebest then I guess that'd be a different effort, but it would be nice to kill startls (and therefore possibility of un-encrypted connections) and any mention of dialback in 6120 at least
  596. @Alacer has left
  597. Dave Cridland has left
  598. zinid I think dialback makes sense, not every admin understands PKIX currently
  599. moparisthebest wow then they need to stop being an admin
  600. moparisthebest retire, start another career they can do
  601. zinid that's rude
  602. Ge0rG Potato farming is a thing
  603. moparisthebest you don't need to have a full understanding of everything involved in PKIX or anything
  604. zinid I kinda agree, but don't want to lose customers 😉
  605. zinid moparisthebest, I don't say "full"
  606. moparisthebest but if you don't understand how to get/use a TLS certificate in 2018, then you should not be an admin of any type of server
  607. zinid so your solution is to replace admins?
  608. efrit has left
  609. moparisthebest I haven't met an admin that couldn't do it
  610. moparisthebest if such an admin exists and refuses to learn, yes, replace them
  611. zinid moparisthebest, the problem is that XSF cannot replace admins
  612. ralphm has left
  613. moparisthebest it's getting impossible to run http without https, if it's good enough for http, it's surely good enough for xmpp
  614. zinid impossible?
  615. zinid how that? I run it without https
  616. moparisthebest it's *getting* impossible
  617. zinid but not impossible so far
  618. moparisthebest you are missing out on all the new features, and are guaranteed to never get new features (new compression, like brotli, http2, etc etc)
  619. moparisthebest *and* soon browsers will issue ugly 'insecure' warnings
  620. zinid yeah, the dream of cryptobitches
  621. Zash I hope you enjoy the future where you must get permission from some authority to host a website.
  622. zinid Zash, only a restricted list of authorities 😉
  623. @Alacer has joined
  624. moparisthebest you can self-sign just like always
  625. Zash Ha, good luck with that
  626. moparisthebest just import it into your trusted CA list on every machine 😛
  627. zinid moparisthebest, but self-sign doesn't work already
  628. zinid also, dialback resolves the issue: you can self-sign
  629. Zash Dialback is pretty terrible tho
  630. moparisthebest I think dnssec+dane solves the issue without CAs too right?
  631. Ge0rG I love how browsers have made self-signed SSL appear less secure than plain-text HTTP.
  632. moparisthebest not for you poor .im victims
  633. moparisthebest but for normal people 🙂
  634. Zash Browsers hate DANE, so good luck with that
  635. moparisthebest I meant for xmpp
  636. moparisthebest as a dialback alternative
  637. Zash has left
  638. marc has joined
  639. Steve Kille has left
  640. Steve Kille has left
  641. jjrh has left
  642. jjrh has left
  643. Zash has left
  644. Dave Cridland has left
  645. hannes has joined
  646. moparisthebest Ge0rG, yea they are in the process of fixing that , already as of oct 2017 any http sites with forms are marked 'not secure' https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure
  647. Steve Kille has joined
  648. Ge0rG moparisthebest: but they haven't fixed SRVid certs
  649. moparisthebest that's only an xmpp problem though right?
  650. Ge0rG moparisthebest: no, it's a non-web problem.
  651. moparisthebest what else uses SRV and enforces valid TLS certs?
  652. jonasw moparisthebest, I think mumble can do both
  653. Dave Cridland has left
  654. Dave Cridland has left
  655. Ge0rG So how can I test Direct-TLS before activating the SRV records?
  656. moparisthebest Ge0rG, openssl s_client ?
  657. Ge0rG SRV is used by LDAP, SIP and... *Minecraft*!
  658. moparisthebest but I think most don't enforce valid TLS
  659. jjrh has left
  660. jjrh has left
  661. moparisthebest Ge0rG, I think you'd test it like openssl s_client -connect xmpps.conversations.im:443 -servername conversations.im -alpn xmpp-client
  662. jjrh has left
  663. Dave Cridland has left
  664. Dave Cridland has left
  665. marc has left
  666. Ge0rG I think prosody will ignore the alpn part.
  667. jjrh has left
  668. uc has joined
  669. jjrh has left
  670. moparisthebest sslh in front of it might not though
  671. moparisthebest -servername and -alpn may not be needed depending on server setup
  672. Ge0rG But yeah, got it now. If I don't send a proper stream header, it will fall back to HTTPS
  673. jjrh has left
  674. Ge0rG _xmpps-client._tcp.yax.im has SRV record 5 1 443 xmpp.yaxim.org.
  675. Ge0rG Let's see how it works out.
  676. moparisthebest does yaxim (the client) support that now?
  677. jjrh has left
  678. georg has joined
  679. Ge0rG moparisthebest: no :(
  680. georg has left
  681. jjrh has left
  682. moparisthebest well if you add support watch the srv fallback logic, all 3 clients I've seen with support initially were broken on at least invalid xml being returned 🙂
  683. moparisthebest I need to setup like bad.example.org for some test cases or something, one day
  684. Syndace has left
  685. uc has joined
  686. ralphm has joined
  687. jjrh has left
  688. jonasw define broken
  689. Zash has left
  690. Syndace has joined
  691. moparisthebest jonasw, well, most fell back only if TCP connect to port failed, invalid TLS cert would be a different error and would abort switching to next SRV record
  692. moparisthebest or invalid XML would abort the attempts
  693. moparisthebest things like that
  694. Ge0rG So my server is slowly accepting more and more connections on :443.
  695. Syndace has left
  696. Syndace has joined
  697. moparisthebest Ge0rG, how do you have it set up? I can't tell from my end
  698. moparisthebest usually I'd just 'openssl s_client -connect -servername yax.im -alpn xmpp-client', type something, hit enter, and either get junk from nginx or prosody 🙂
  699. Ge0rG moparisthebest: mod_net_multiplex on :443
  700. moparisthebest I don't get anything from your server though
  701. Ge0rG moparisthebest: give it a valid XML stream
  702. Ge0rG It's been enabled for a year, but I never managed to test and add the SRV record.
  703. Syndace has left
  704. Syndace has joined
  705. jjrh has left
  706. moparisthebest hmm I can't find any docs on that module, didn't know it existed
  707. Flow moparisthebest: so an invalid cert should be ignored and the next SRV RR tried?
  708. moparisthebest Flow, I think so, why not?
  709. jjrh has left
  710. Flow moparisthebest, dunno, do browser try a different A/AAAA RR if the cert is invalid?
  711. moparisthebest probably not, but those aren't SRV records where you *should* try next
  712. Flow well only by priority
  713. Flow and it's also debatable if an invalid cert should trigger a fallback
  714. Flow but if that's what we want, then xep368 should mention it
  715. moparisthebest what about invalid xml ?
  716. moparisthebest I actually don't know, it should follow same rules as normal starttls srv fallback I guess
  717. moparisthebest https://tools.ietf.org/html/rfc6120#section-3.2.1 "6. If the initiating entity fails to connect using that IP address but the "A" or "AAAA" lookups returned more than one IP address, then the initiating entity uses the next resolved IP address for that FDQN as the connection address."
  718. Flow I never saw such rules ;)
  719. Flow well those I saw
  720. moparisthebest I guess the debate is what 'fails to connect' means 🙂
  721. moparisthebest I would class any errors as a failure and fallback
  722. moparisthebest including invalid XML or invalid TLS cert=
  723. Flow anyway, SRV fallback on invalid cert would possibly be a good idea to aid cert migration or so
  724. SamWhited I disagree; SRV fallback should only happen if there are errors during the TCP connection. Afterwards you're done with SRV and can throw the records away, because you have a connection to a thing in the SRV record.
  725. jonasw moparisthebest, I’m not sure that "try another SRV record" is the appropriate course of action if one SRV records yields invalid XML...
  726. moparisthebest why not jonasw ?
  727. jonasw I’m just not sure :)
  728. SamWhited SRV/TCP connection and the application layer protocol are two different layers of the stack that shouldn't be mixed.
  729. moparisthebest if so xep-368 is useless and should be abandoned 😛
  730. Flow jonasw, "SRV records yields invalid XML"?
  731. jonasw Flow, s/if one SRV records/if a server on a specific SRV record/
  732. jonasw moparisthebest, why?
  733. moparisthebest try any account on burtrum.org over ipv4 on any client that doesn't implement ALPN (dino for instance)
  734. moparisthebest it fails to connect, because if you don't send alpn, you get a non-xml response from nginx
  735. jonasw moparisthebest, you should have written that in the XEP
  736. Flow I'm usually a fan of fail fast, but after thinking some more about it: What can you loose by trying a lower priority SRV RR?
  737. jonasw clients do not have to set the ALPN. it thus has to work without it.
  738. moparisthebest right, I think it's in there
  739. moparisthebest Server operators should not expect multiplexing (via ALPN) to work in all scenarios and therefore should provide additional SRV record(s) that do not require multiplexing (either standard STARTTLS or dedicated direct XMPP-over-TLS).
  740. moparisthebest so I have additional SRV records that don't require ALPN, because I expect clients to fall back 🙂
  741. jonasw I think the error modes clients have to expect should be spelt out explicitly
  742. SamWhited "standard STARTTLS" uses a completely different set of SRV records, it's not part of normal SRV fallback. It requires making a different connection using a different record.
  743. jonasw I’m pretty sure that bad things™ happen with aioxmpp
  744. jonasw and probably no fallback
  745. jonasw SamWhited, it does, that’s specified in XEP-0368
  746. SamWhited jonasw: what does what?
  747. moparisthebest SamWhited, that xep suggests mixing them as if they are one set of SRV records
  748. jonasw SamWhited, it is (part of the normal SRV fallback), that’s specified in XEP-0368
  749. Flow what jonas said, the xep should mention it, especially since we have evindence that most developers forget about the fallback case(s)
  750. SamWhited Oh geeze, I thought that got taken out. That makes no sense and I will be ignoring it.
  751. moparisthebest when I wrote it I assumed fallback would just work, I had to make it work in conversations
  752. moparisthebest but yea I'm just now noticing clients not handling it well
  753. jonasw SamWhited, it’s "just" a SHOULD, but in fact the first point in the rules :)
  754. moparisthebest so I agree, that should be in implementation notes now 🙂
  755. Dave Cridland has left
  756. jonasw moparisthebest, clients probably have very specific rules on what allows a fallback, with everything else leading to an explicit and early error fully out of the stack
  757. moparisthebest yes it used to be MUST but someone ( ralphm I think) pointed out they might want to JUST query xmpps-client
  758. SamWhited I doubt most DNS libraries will work that way, so unless you're willing to do some weird hackery or do your own SRV logic you're not going to be able to mix two different SRV record sets anyways (I suspect, admittedly, that's just a guess)
  759. jonasw are there DNS libraries which handle SRV logic? ;-)
  760. jonasw I had to roll that myself, too
  761. moparisthebest most I've seen give you a list, and you have to sort/try them yourself
  762. jonasw that
  763. moparisthebest but does anyone see harm in falling back in any type of 'non-success' ?
  764. moparisthebest or at least, invalid TLS or invalid XML
  765. jonasw yes.
  766. moparisthebest like where a connection is not established
  767. jonasw authentication failure is probably a bad idea to fall back on
  768. jonasw or lack of a (client-)required stream feature
  769. moparisthebest yes was going to say not that
  770. Flow jonasw: https://github.com/MiniDNS/minidns/blob/master/minidns-hla/src/main/java/de/measite/minidns/hla/ResolverApi.java#L183
  771. moparisthebest well, auth
  772. SamWhited Yah, I don't know what the issue would be, but I suspect mixing various layers of the stack like that will just lead to issues, possibly security issues.
  773. moparisthebest a lack of client-required stream feature, why not fall back?
  774. moparisthebest maybe the next server has what you are looking for?
  775. jonasw Flow, I can’t tell from the code whether that does the sorting?
  776. Flow jonasw, it does the right thing™
  777. jonasw moparisthebest, because the servers are supposed to be identical
  778. moparisthebest jonasw, why? where does it say that?
  779. SamWhited Or, at best, just make development *much* harder since you won't be able to separate your XMPP stuff from your SRV/DNS stuff.
  780. Flow (so sorting and taking weight into consideration)
  781. jonasw Flow, so it returns an iterable of SRV records which I can try in that order?
  782. Flow jonasw, yep
  783. jonasw Flow, okay
  784. jonasw does it select records from the same priority randomly or does it allow you to try multiple of the same priority?
  785. jonasw (when I asked about that a year ago or so, people suggested that trying all records from the same priority set on some errors would probably be a good idea)
  786. Flow hmm fallback on invalid XML and cert, yes, but on authentication failure? no…
  787. jjrh has left
  788. moparisthebest yea I think maybe that would be a sensible place to draw the line
  789. jonasw moparisthebest, it doesn’t make sense to me logically that the same identity would offer different stream features depending on the interface I use to connect to it
  790. moparisthebest if you get to authentication, quit, otherwise fallback
  791. Flow jonasw, I don't think that you are supposed to try multiple RRs from the same priority
  792. moparisthebest jonasw, why, maybe they run ejabberd on one server and prosody on the other and have some home-grown thing to connect them?
  793. SamWhited How does your SRV code know that you've gotten to auth or that there was an XML error? You're forcing much tighter coupling than is necessary by making application level errors affect behavior in the TCP layer
  794. valo has joined
  795. jonasw sure you could be doing that, with a lot of pain, it would probably work for a minute or two, but I don’t think that’s a case we should plan for. in the best case, it only delays the error from reaching the user, which can be for quite some time on a bad connection.
  796. Flow uhh, a heterogeneous xmpp server cluster, want!
  797. moparisthebest SamWhited, I think the sane system is your SRV code gives you a List<(ip, port, direct_tls_bool)> and then you try them in order?
  798. jonasw SamWhited, my SRV code provides an iterable of connection options which are then tried in order (until either one succeeds or a fatal (e.g. authn-failed) error occurs)
  799. moparisthebest that's at least how conversations works
  800. jonasw the SRV code is over at that point
  801. SamWhited moparisthebest: what if my connection library is entirely self contained? (eg. the connection library I wrote which just "dials" an XMPP socket and hands you a raw TCP socket back to use)
  802. moparisthebest then you should rework that 😛
  803. SamWhited My SRV code does not touch or know anything about my XMPP code and I should be able to keep it that way; they're completely unrelated.
  804. jonasw SamWhited, I think your dial does too much
  805. moparisthebest I don't see anywhere where SRV says fallback only in the event of TCP not connecting
  806. jonasw users may have legitimate reasons to override the SRV lookup
  807. jonasw (e.g. during testing)
  808. moparisthebest not even rfc6120
  809. jonasw so having those two functions separate is definitely required
  810. moparisthebest it uses a vague 'fails to connect' language
  811. jonasw and once you’ve got there, you can properly decouple the two (srv lookup and dial) and provide a third which mixes both
  812. jonasw (i.e. iterates over the records and tries them until either success or fatal error, where not every error is fatal)
  813. moparisthebest in fact SRV couldn't say that, because it supports things other than TCP that don't have a defined 'connection'
  814. SamWhited I don't see how it's doing too much; you call dial and it looks up SRV records and tries them until it gets a valid connection then hands them back. That's about as simple and self-contained of a library as you can get.
  815. moparisthebest but regardless, sounds like we could use some good on-list discussion about proper SRV fallback behavior
  816. jonasw moparisthebest, that sounds sensible
  817. moparisthebest and then put some if not all of it in xep-368
  818. SamWhited If the end user wants to "override" SRV behavior they can pass a different socket into the XMPP library and not use the SRV dialing library
  819. moparisthebest I guess waiting so long before final turns out to be a good idea 🙂
  820. jonasw SamWhited, ah I see
  821. moparisthebest SamWhited, wouldn't a lib like that take a username+password ?
  822. moparisthebest in which case it'd know if it reached auth yet
  823. SamWhited moparisthebest: no, it's just dialing TCP connections, it doesn't know anything about XMPP
  824. moparisthebest oh, well, that's odd
  825. jonasw I tend to agree
  826. moparisthebest especially for direct TLS
  827. SamWhited It just knows to do a query for "xmpps-client" or whatever and get some records back, then it tries them (based on priority) until it gets a valid connection.
  828. jonasw yeah, I don’t think that’s good
  829. SamWhited Why not?
  830. Flow define "valid connection"
  831. SamWhited "a tcp socket was established"
  832. moparisthebest so it doesn't check TLS cert either?
  833. Flow there you have your issue
  834. SamWhited I can't remember, it might do TLS
  835. ralphm has joined
  836. jonasw SamWhited, the server could be telling you that it is out of capacity currently
  837. moparisthebest a xmpp connection is in my opinion a negotiated stream over a valid TLS connection
  838. moparisthebest so like, after you get that far, maybe don't fallback
  839. moparisthebest but before you should absolutely fallback
  840. Flow mopharisthebest: I wonder how you noticed that the implementations did not perform a fallback in those cases? Did that cause you any usability issues? Or did you just look at the code?
  841. moparisthebest Flow, yea I fired up dino and it failed to connect 😛
  842. Flow ahh because of alpn
  843. moparisthebest same with conversations with my initial patch, but I was already deep in that code so I fixed it
  844. jjrh has left
  845. SamWhited I disagree, SRV/TCP is a transport layer thing, XML/XMPP are an application layer thing. Mixing the two will just lead to complexity and possibly security issues.
  846. moparisthebest SamWhited, SRV has nothing to do with TCP and therefore nothing to do with connections
  847. moparisthebest if you want to go up that high
  848. moparisthebest imagine a _udp SRV record, what a successfull connection entails is entirely application layer
  849. moparisthebest same here imho
  850. Flow yep, it feels like SRV records to be more at the application layer
  851. SamWhited Yah, I actually have some separation there too but it's not relavant for this discussion
  852. SamWhited But the retrying is just about dialing TCP sockets, it's definitely not application layer
  853. jonasw SamWhited, it could also simply timeout after accepting the TCP connection
  854. moparisthebest still disagree
  855. jonasw because the server is massively overloaded
  856. SamWhited Or rather, not application protocol layer. It has nothing to do with XMPP and I don't want it to know about XMPP.
  857. jonasw and you should be trying the next one
  858. jonasw you can’t tell that purely from the TCP layer
  859. moparisthebest then how do _udp SRV records work?
  860. jonasw SamWhited, make XMPP know about the SRV records, not the SRV records know about XMPP.
  861. SamWhited These aren't udp SRV records, but fair enough, I don't know
  862. la|r|ma has left
  863. SamWhited jonasw: now my XMPP library can't work over a unix domain socket or a random in-memory pipe or something else. It's tightly coupled to my library that dials TCP connections
  864. jonasw SamWhited, not necessarily
  865. moparisthebest basically you are saying SRV should apply only to TCP connections and I'm saying they should apply to XMPP connections, of which a TCP connection is just the first part, I think
  866. moparisthebest I don't think either stance is necessarily wrong or right, just needs to be agreed upon and written down and followed 🙂
  867. jonasw as I said earlier; in my design, the SRV stuff simply gives a list of connector objects; that list is appended to the list of connector objects supplied by the current connection (if any; used e.g. for XEP-0198 @location). it’s easy to add a UnixDomainConnector and use that.
  868. moparisthebest but I didn't really think about it apparantly, and if SRV really stops falling back at successful TCP, parts of 368 are incorrect and need fixed
  869. SamWhited At worst I think mixing the dialer/TCP stuff with XMPP error logic could be a security issue, at best I think it needs to not be specified and just left to be an implementation detail. If my library doesn't retry on invalid XML and yours does, it's not a compatibility issue so why specify that behavior?
  870. moparisthebest well then your library doesn't work with my server
  871. moparisthebest which I guess is fine, unless my server happens to be huge like conversations.im or something
  872. jonasw SamWhited, it is a compatibility issue with XEP-0368 servers which require ALPN.
  873. Flow the xep should at least recommend fallback on invalid cert/xml
  874. moparisthebest I have to patch 368 support out of dino to use it currently, for example
  875. jonasw moparisthebest, would you care to fire an aioxmpp exmaple against your server?
  876. moparisthebest as added fun, my server does not require alpn over ipv6 😛 (which, having unlimited addresses, I multiplex that way instead of sslh...)
  877. SamWhited Why is it a compatibility issue there? If you have a server with ALPN why would you mix records that use ALPN and a dedicated IP that doesn't use it? If you have an IP for that particular server, you don't need ALPN, or did I misunderstand that?
  878. moparisthebest jonasw, I can make you a test account if you like
  879. jonasw moparisthebest, EBUSY currently
  880. jonasw and I’ll likely forget about it :/
  881. moparisthebest SamWhited, directly from xep-368 "Server operators should not expect multiplexing (via ALPN) to work in all scenarios and therefore should provide additional SRV record(s) that do not require multiplexing (either standard STARTTLS or dedicated direct XMPP-over-TLS)."
  882. jonasw SamWhited, xmpps-server requiring ALPN over v4, but not over v6 and in addition a fall-abck xmpp-server RR seems like a reasonable setup
  883. moparisthebest which obviously expects clients to fallback when hit with invalid xml or whatever
  884. jonasw moparisthebest, I don’t find that obvious tbh :)
  885. jonasw but that may simply be my lack of domain knowledge
  886. moparisthebest jonasw, well obvious to me, but in hindsight, I fully agree with you 😛
  887. moparisthebest again, no one ever accused me of being an english wizard 😛
  888. SamWhited Ah, this is about falling back to STARTTLS, that I also think is a bad thing, mixing SRV records just feels like it's going to cause problems and unexpected behavior, though again I'm not sure how
  889. moparisthebest well, or falling back at all
  890. moparisthebest I think my current SRV setup is 443 first (which requires alpn or you get invalid xml) and then 5223 next
  891. moparisthebest and then 5222/starttls
  892. moparisthebest if we decide fallback stops at tcp connect I'd need to move priority to 5223 first, 5222 second, 443 last
  893. SamWhited Tangentially related but not about the current discussion: If you had ALPN on 443 doesn't HTTP require ALPN? So you could make your XMPP server the default if no ALPN protocol is specified and assume browsers will do ALPN properly and HTTP will always work?
  894. moparisthebest you could, only http2 browsers will do it though
  895. SamWhited ahh, right
  896. moparisthebest which is most newish/secure ones for sure
  897. SamWhited Will they do it for http/1.1 as well though, or just http/2?
  898. moparisthebest I think they do it for both
  899. moparisthebest I know http/1.1 is defined, not sure if I've ever actually checked honestly
  900. moparisthebest also this would need updated https://wiki.xmpp.org/web/Tech_pages/XEP-0368
  901. moparisthebest in hindsight I fully assumed fallback would happen regardless 🙂
  902. jjrh has left
  903. jjrh has left
  904. jjrh has left
  905. Alex has left
  906. Tobias has left
  907. Alex has joined
  908. jjrh has left
  909. uc has joined
  910. valo has left
  911. valo has joined
  912. daniel has left
  913. daniel has joined
  914. jjrh has left
  915. daniel has left
  916. jjrh has left
  917. daniel has joined
  918. jonasw has left
  919. daniel has left
  920. daniel has joined
  921. Dave Cridland has left
  922. Guus has left
  923. jjrh has left
  924. jjrh has left
  925. lskdjf has left
  926. ralphm has joined
  927. had-hoc has left
  928. ralphm has left
  929. goffi has left
  930. Guus has left
  931. jere has joined
  932. daniel has left
  933. daniel has joined
  934. had-hoc has joined
  935. jere has joined
  936. daniel has left
  937. daniel has joined
  938. Flow has joined
  939. zinid moparisthebest, "prosody legacy port"
  940. moparisthebest zinid, yea prosody devs need to alias that to 'direct_tls_port' 😛
  941. zinid moparisthebest, I think the article shouldn't assume the server name
  942. moparisthebest zinid, what does ejabberd call it? I assume something similar
  943. zinid just replace prosody with 'xmpp server'
  944. zinid the text is valid for all servers
  945. moparisthebest well I wanted to be explicit, I'll put 'prosody legacy_ssl_port' or ejabberd whatever_that_calls_it
  946. zinid nginx
  947. zinid what if I use haproxy?
  948. ralphm has joined
  949. moparisthebest it's not a spec it's an example
  950. zinid ok, so I will copy it, replace names and submit to the wiki?
  951. zinid because I cannot refer to the article in this version
  952. moparisthebest sure if it's useful 😛
  953. moparisthebest it's more meant for people who followed a tutorial to set up prosody or something
  954. moparisthebest people who can read specs probably don't need it
  955. zinid as I said above, sslh config is the same for *any* xmpp/imap/http server
  956. moparisthebest yes, but if I say like 'xmpp server direct tls port' then you have to search docs to discover what that's named
  957. moparisthebest so I'd like to say xmpp server direct tls port (prosody legacy_ssl_ports, ejabberd whatever_its_called)
  958. zinid what?
  959. moparisthebest and then https port (nginx, apache)
  960. moparisthebest or whatever, in the comments
  961. moparisthebest I thought it was pretty obvious you didn't *have* to use prosody
  962. moparisthebest but feel free to update the wiki with ejabberd name or whatever too, it's a wiki
  963. zinid nah, it is better to rename the page to prosody-nginx-openssh-dovecot related configuration
  964. zinid then I'm fine with it
  965. moparisthebest haha
  966. zinid anyway, I don't remember my account credentials, so
  967. moparisthebest if you set up ejabberd and haproxy and tiny-ssh and cyrus-imap and can't figure out how to apply that config to your setup, oh well
  968. zinid moparisthebest, nice logic
  969. zinid moparisthebest, why didn't you put 'prosody' everywhere in xep-0368 instead of 'xmpp server'?
  970. zinid if someone can't figure that, oh well...
  971. moparisthebest because it's a spec, not a friendly hand-holdy example 😛
  972. zinid but your logic still applies
  973. moparisthebest it's like a tutorial or an example, that's all
  974. moparisthebest make it too generic and it gets useless, like I said, I'm fine with adding what ejabberd calls it in there
  975. zinid ejabberd doesn't call anything related to this
  976. zinid listen: - port: 5223 module: ejabberd_c2s tls: true ...
  977. zinid not sure what should be called here and why
  978. moparisthebest and that implied direct tls ?
  979. moparisthebest *implies
  980. zinid yes, and `starttls: true` implies starttls, who would have thought that 🙂
  981. edhelas has left
  982. moparisthebest do you have to specify one or the other?
  983. edhelas has joined
  984. zinid no, if you don't need (start)tls at all
  985. zinid but you cannot specify both
  986. moparisthebest if you don't does it imply starttls ?
  987. Alex has left
  988. zinid no, it implies no starttls
  989. zinid plain connection
  990. SamWhited has left
  991. moparisthebest check that edit zinid https://wiki.xmpp.org/web/Tech_pages/XEP-0368 better?
  992. zinid yes, much better, thanks
  993. moparisthebest np, thanks for ejabberd config info!
  994. edhelas has left
  995. edhelas has joined
  996. zinid does dino support ALPN?
  997. Alex has joined
  998. winfried has left
  999. winfried has left
  1000. winfried has left
  1001. winfried has joined
  1002. Zash has left
  1003. blabla has joined
  1004. Zash has joined
  1005. moparisthebest zinid: not currently that's how I discovered the broken fallback
  1006. valo has joined
  1007. zinid has left
  1008. Dave Cridland has left
  1009. Dave Cridland has left
  1010. Dave Cridland has left
  1011. Zash has left
  1012. zinid has joined
  1013. lskdjf has left
  1014. zinid moparisthebest: I see
  1015. winfried has joined
  1016. blabla has left
  1017. blabla has joined
  1018. Alex has left
  1019. Dave Cridland has left
  1020. lskdjf has left
  1021. Dave Cridland has left
  1022. lskdjf has left
  1023. lskdjf has left
  1024. bra has joined
  1025. vanitasvitae has left
  1026. vanitasvitae has joined
  1027. jere has joined
  1028. lskdjf has left
  1029. Dave Cridland has left
  1030. vanitasvitae has left
  1031. lskdjf has left