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 212.21.75.16:443 -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