XSF Discussion - 2018-01-08

  1. Dave Cridland

    Afternoon, all.

  2. SouL


  3. Dave Cridland

    Just submitted one Internet Draft, plus two ProtoXEPs, covering adding TOTP-based 2FA to XMPP.

  4. Dave Cridland

    edhelas, You might be interested in that, as I recall.

  5. edhelas

    link ?

  6. jonasw

    two(!) protoxeps

  7. jonasw

    you want me to fail my exams!!!k

  8. jonasw

    I may take care of them tonight

  9. Dave Cridland

    jonasw, No problem.

  10. Dave Cridland

    jonasw, As in, no rush - not that your exams aren't a problem.

  11. jonasw

    I understood, and also I was joking :)

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

  13. Dave Cridland

    edhelas, The Internet Draft is here: https://datatracker.ietf.org/doc/draft-cridland-kitten-clientkey/

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

  15. Dave Cridland

    edhelas, It demands a few supporting functions from the containing protocol, which is the other ProtoXEP.

  16. edhelas

    okay good

  17. edhelas

    will have a look at it asap

  18. Ge0rG

    Dave Cridland: how often is it supposed to ask for TOTP veriifcation?

  19. Dave Cridland

    Ge0rG, Without the CLIENT-KEY mechanism? Every time.

  20. Ge0rG

    Dave Cridland: this question is generally interesting to me in the context of long-living TCP sessions, but also for 0198 and ISR

  21. Dave Cridland

    Ge0rG, That would, of course, be nuts.

  22. Ge0rG

    Dave Cridland: and with client key?

  23. Dave Cridland

    Ge0rG, With CLIENT-KEY, it wouldn't. But CLIENT-KEY has expiry and things built in, to force users to reauthenticate.

  24. jonasw

    Dave Cridland, Builds/xeps/inbox/totp-2fa.xml: not well-formed (invalid token): line 99, column 61

  25. Dave Cridland

    jonasw, Yeah, the ABNF. On it...

  26. Ge0rG

    Dave Cridland: will CLIENT-KEY expiry close the session, or require an in-session reauth?

  27. Dave Cridland


  28. Ge0rG

    So if I have a good network, I can stay logged in forever?

  29. jonasw

    at some point, the servers certificate will expire and your client will of course disconnect you :)

  30. Dave Cridland

    Ge0rG, Sure. I imagine if a server admin thought this was a problem they could put in a session expiry.

  31. Ge0rG

    jonasw: I LOLed.

  32. jonasw

    sleekxmpp actually does that.

  33. Kev

    Presumably if there is an issue with authentication of long-lived sessions, this goes beyond the tokens, and would apply to all sessions.

  34. Kev

    Seems orthogonal to this.

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

  36. Dave Cridland

    jonasw, Travis is back doing its magic on an update.

  37. jonasw

    Dave Cridland, not sure. If I actually managed to steal a certificate, long-running sessions would fall for me longer than needed.

  38. Dave Cridland

    jonasw, Quite possibly. But that's not what the certificate expiry is for.

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

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

  41. jonasw

    Dave Cridland, built for website in progress, ETA 2h

  42. mathieuii

    Dave Cridland, maybe the namespace would be better as urn:xmpp:totp:0? "mfa" is a bit broader than TOTP

  43. 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 :)

  44. Steve Kille


  45. Steve Kille

    and thanks

  46. jonasw

    build in progress, ETA ≤ 2h

  47. mathieuii

    one of my concerns is that most services offering TOTP have "recovery codes" the user can use when they lose their secret

  48. Ge0rG

    mathieuii: is that a sentiment about lack of security of 2FA implementations?

  49. mathieuii

    not security, rather improved security leading to account locking

  50. Ge0rG

    it should be really hard but not impossible to recover from a 2FA loss

  51. mathieuii


  52. mathieuii

    well, currently there’s no standard for password recovery either, so that’s consistent at least

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

  54. jonasw

    isn’t that the whole idea of ISR+0198?

  55. Ge0rG

    jonasw: yes

  56. Ge0rG

    jonasw: but consider a pre-ISR pre-CLIENT-KEY world, where the user enters a TOTP token value on each login.

  57. Ge0rG

    how long should that authenticated session be considered valid? Until the expiry of the server SSL cert?

  58. Ge0rG

    Hi Flow! Were just talking about you ;)

  59. Flow

    what a coincidence :)

  60. MattJ

    It's similar to the question of whether s2s connections should close when the cert that was used to authenticate them expires

  61. Ge0rG

    I tend to agree with Kev that it's somewhat orthogonal to SSL cert lifetime, though.

  62. Ge0rG

    The question still remains, how long and under which conditions a session should be considered valid.

  63. Ge0rG

    TLS session reuse also comes to mind in this context.

  64. Ge0rG

    But I'm not very inclined to outsource the reauth of a layer 7 client session to TLS.

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

  66. Zash

    Do you stop being you when your cert expires?

  67. mathieuii


  68. Ge0rG

    Zash: you can't know for sure.

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

  70. Ge0rG

    Why must everything be a SASL mechanism?

  71. Dave Cridland

    Ge0rG, Because it's an authentication, and that's where authentications live in XMPP.

  72. Ge0rG

    So it requires to re-login to enter the unlock code?

  73. Dave Cridland

    Ge0rG, No, an unlock code *is* an authentication.

  74. Ge0rG

    Dave Cridland: oh, maybe I have a different understanding of that term then.

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

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

  77. Ge0rG

    Dave Cridland: what you are describing sounds like a password|credentials reset mechanism, which of course _is_ an authentication

  78. Dave Cridland

    Ge0rG, Ah, I see. No, I was meaning the codes to unlock/recover an account when the TOTP is lost.

  79. Ge0rG

    so maybe "account recovery" would be a better term, then

  80. Dave Cridland

    Ge0rG, Yeah, probably.

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

  82. Ge0rG

    Though I must admit I don't particularly like that approach.

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

  84. Ge0rG

    This is pretty similar to account recovery, though.

  85. marc

    Ge0rG, didn't follow the discussion but the account doesn't exists in my approach

  86. Ge0rG

    marc: how do you ensure that nobody else registers the same account?

  87. marc

    Ge0rG, checking :)

  88. Ge0rG

    marc: this answer is insufficient.

  89. marc

    Ge0rG, for user invitation you don't have the problem

  90. marc

    for account creation the account name is reserved

  91. Ge0rG

    marc: the easiest way to reserve an account name is to regiser that account, isn't it?

  92. marc

    Ge0rG, no, because the invitation may expire

  93. marc

    account creation

  94. Ge0rG

    Ah, right.

  95. marc

    Puh, I expected a big discussion :D

  96. marc

    I should write this down right now...

  97. marc

    Ge0rG, btw, we still need the ibr=true query parameter, right?

  98. Ge0rG

    marc: yes

  99. marc

    okay, good

  100. jonasw

    marc, how’s your progress on submitting the protoxep?

  101. marc

    jonasw, what does submitting mean? Official submitting or publishing it on my web server?

  102. jonasw

    marc, the former

  103. jonasw

    a PR to the xeps repo

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

  105. marc

    I don't know how a protoXEP should look like before submitting it

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

  107. Ge0rG

    The end is nigh! https://techcrunch.com/2018/01/08/telegram-open-network/

  108. mathieuii

    "Durov’s idea is to launch an entirely new blockchain" send help

  109. marc

    jonasw, I need a better motivation and probably some other stuff is missing

  110. marc

    jonasw, I try to push it to my webserver tomorrow

  111. marc

    So you guys can look at it, give some feedback before pushing it to xsf repo

  112. Ge0rG

    marc: I can help you writing some sections. Just give me a git 😜

  113. jonasw

    I feel that this feedback should happen in official protoxep or even experimental state.

  114. Ge0rG

    I've submitted the astonishing number of 1 xeps already.

  115. marc

    jonasw, I don't think so because I expect that there will be some really basic mistakes etc.

  116. jonasw

    marc, don’t worry about that

  117. marc

    Ge0rG, will give you a Git tomorrow I think

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

  119. Ge0rG

    marc: 👍🏽

  120. Dave Cridland

    jonasw, +1 to that.

  121. Dave Cridland

    Or more generally, if it's worth working on, it's worth submitting.

  122. zinid

    Ge0rG, > Durov and his brother Nikolai Durov, a mathematical genius I lol'd. Who wrote this?

  123. Ge0rG

    zinid: probably a journalistics genius.

  124. Dave Cridland

    Man, that's one seriously transparent Poniz scheme.

  125. Dave Cridland

    Man, that's one seriously transparent Ponzi scheme.

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

  127. zinid

    of course BFT is slower, especially the one with timeouts

  128. Ge0rG

    Now stop bashing the Durovs and let's focus on our own ICO! JabberCoin!

  129. Ge0rG

    I even have a motto for it already: "The brightest light [or lamp?] in crypto moneys!"

  130. intosi


  131. moparisthebest

    introducing, JabberCoin! (5 minutes later, sued to death by cisco...)

  132. zinid

    there is already a shitcoin

  133. Ge0rG

    Oh, right. That trademark thing.

  134. Ge0rG

    zinid: so we make a JIDcoin

  135. moparisthebest

    zinid, a ? like only 1 ?

  136. Dave Cridland

    moparisthebest, The XSF can license us, though.

  137. Ge0rG

    Dave Cridland: I'm not sure we can have something that starts with "jabber" and is a commercial entity from the XSF.

  138. zinid

    moparisthebest, https://github.com/shitcoin/shitcoin

  139. Ge0rG

    From my last reading of the terms, it needs Cisco approval.

  140. Ge0rG ,oO( Initial Github Offering? )

  141. zinid

    created a bug report: https://github.com/shitcoin/shitcoin/issues/6

  142. moparisthebest

    zinid, I'd give that coin an award for truth in advertising

  143. Dave Cridland

    Ge0rG, Yes, you're right.

  144. Ge0rG

    Dave Cridland: that's almost the only thing stopping me from creating the Jabber Software Foundation. That, and a lack of volunteers.

  145. Dave Cridland

    Ge0rG, If it's non-profit you could.

  146. Ge0rG

    Dave Cridland: I can't even get people to sign my anti-spam manifesto. How am I supposed to build up a Foundation?

  147. zinid

    what manifesto?

  148. moparisthebest

    Starting from the bottom usually

  149. Ge0rG

    zinid: https://gist.github.com/ge0rg/2e4accf6950821ca45f743fdf587c08e

  150. Dave Cridland

    Ge0rG, With your natural charisma?

  151. zinid

    not sure what is the goal of the manifesto

  152. zinid

    to reach a consensus?

  153. Ge0rG

    zinid: to make a public statement about blocking and shaming abandoned servers.

  154. MattJ

    To reach a long list of good spam-free servers

  155. moparisthebest

    zinid: get major server admins to agree?

  156. zinid

    ok, and what practical implications?

  157. jonasw

    Ge0rG, where did you even advertise that?

  158. Ge0rG

    jonasw: the manifesto? I asked some server admins so far

  159. MattJ

    zinid, if you're not on the list, people may limit/filter/block traffic from your server

  160. moparisthebest

    jonasw agreed to operate an rbl right? :)

  161. zinid

    MattJ, nice 🙂

  162. zinid

    but what if I don't run a public server? I'll be blocked too?

  163. MattJ

    If you don't originate spam, I doubt it :)

  164. jonasw

    moparisthebest, I did

  165. Ge0rG

    XMPP spam is Russian. zinid is Russian. Might get blocked by accident.

  166. jonasw


  167. jonasw

    block ru TLD, be done with spam ;-)

  168. Ge0rG

    jonasw: no, they are using IBR servers all over the world. Need to block cyrillic letters instead.

  169. jonasw

    I wasn’t serious anyways

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

  171. jonasw

    moparisthebest, yeah, dns it’ll be

  172. jonasw

    I’ll also run this on a dedicated machine. I expect some trouble out of it.

  173. Ge0rG

    jonasw: you should run it on a dedicated uplink then.

  174. jonasw

    Ge0rG, that’s my ISPs job :>

  175. Ge0rG

    in a dedicated data center.

  176. Ge0rG

    on a dedicated Internet.

  177. jonasw

    they have DDoS-protection

  178. jonasw

    at least they advertise it

  179. moparisthebest

    you could just let a big DNS provider take care of it for you

  180. jonasw

    moparisthebest, thought of that, but I wonder how well updates would work with that

  181. moparisthebest

    cloudflare, hurricane electric, I'm sure there are other free ones

  182. moparisthebest

    cloudflare has an API at least

  183. jonasw

    I don’t like cloudflare

  184. Ge0rG

    you could run a hidden primary and have some provider run the secondaries.

  185. moparisthebest

    jonasw, another, yep what Ge0rG said

  186. jonasw

    Ge0rG, that sounds like a good plan.

  187. zinid

    Ge0rG, do you have s2s dialback enabled on yax.im?

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

  189. moparisthebest

    only ones I could find that support everything I needed, dnssec and such too

  190. Ge0rG

    zinid: yes I do

  191. Ge0rG

    moparisthebest: do you have stats from them?

  192. Ge0rG is looking for a new secondary for some zones

  193. jonasw

    Ge0rG, I’ll be happy to :)

  194. moparisthebest

    Ge0rG, what kind of stats?

  195. jonasw

    but no guarantees :)

  196. Ge0rG

    moparisthebest: reliability, speed of zone propagation, such things.

  197. Ge0rG has been using the freendns dyndns service for some 15 years now

  198. moparisthebest

    Ge0rG, so 2 of the 3 providers support the push thing so zone propagation is instant

  199. jonasw

    unfortunately, cloudflare thinks that DNS secondary is an enterprise solution :/

  200. moparisthebest

    I want to say puck.nether.net is the one that takes up to like 10 minutes

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

  202. Ge0rG

    moparisthebest: great!

  203. moparisthebest

    which, is good enough for me, that's why I have 3 different providers and 4 servers 😛

  204. moparisthebest

    the likliehood all 3 are ever down seems slim

  205. jonasw

    anyways, gotta go

  206. Ge0rG

    Monal. Will create an individual notification for each message in a conversation. Won't delete any if you respond from the PC.

  207. moparisthebest

    Ge0rG, this is a good one too (multicast) but no dnssec 😢 https://system-ns.com/services/secondary

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

  209. Ge0rG

    moparisthebest: not that I would care about DNSSEC, with the sad .IM situation

  210. moparisthebest

    yea, what happened with that?

  211. moparisthebest

    last I heard they said they would add support, which had to have been years ago

  212. Ge0rG

    moparisthebest: really? Last thing I heard was "not on the agenda"

  213. Ge0rG

    And that was when DLV was still a thing

  214. moparisthebest

    I thought someone from here contacted them

  215. Ge0rG

    moparisthebest: I did

  216. Ge0rG

    moparisthebest: last time in 2015, "Unfortunately as per our previous correspondence there is still no movement regarding your query."

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

  218. moparisthebest

    wonder if that email still exists, also, you should bug them again Ge0rG 😛

  219. Ge0rG

    I've lost my hope in DNSSEC

  220. moparisthebest

    nowadays I don't buy domains unless they have full dnssec support 😢

  221. moparisthebest

    at least all the new ones are required to have it

  222. Ge0rG

    Sigh. Clients that ignore the bookmarked nickname for 300.

  223. Ge0rG

    And then a gazillion popups from ChatSecure. Looks like it does MUC MAM too, now.

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

  225. Ge0rG

    Kev: I think the most probable outcome is me tele-participating.

  226. Ge0rG

    Even though I always only get 30% through WebEx :(

  227. Ge0rG

    Kev: have you written down any proto-XEP yet?

  228. Kev

    I was hoping to get the Informational thing submitted before the summit, but that's looking very tight now. We'll see.

  229. Kev

    Right, I was just typing that :)

  230. Ge0rG

    Kev: Also, I think last time we limited the scope from XMPP2 down to message routing 2

  231. Kev

    I think we need to cover more than just message routing 2, to be able to advance various things.

  232. Ge0rG

    Kev: various things are good, right?

  233. Kev

    I don't know which of the possible meanings of that you intend.

  234. Ge0rG

    Kev: I hope I can take the time to actually do my presentation; maybe that would be a good prequel to your XMPP2?

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

  236. Kev

    Multi-device sync.

  237. Kev

    Of which message routing is a subset, I think.

  238. Kev

    I think bind2/sasl2 are part of this too, although maybe they don't currently need discussion.

  239. Ge0rG

    Kev: I'd consider multi-device sync as part of the message routing problem.

  240. Kev

    No, definitely the other way around :)

  241. Kev

    Because sync involves both history fetching and read-state synchronising, neither of which is routing :)

  242. Ge0rG

    it's routing to the archive and from the archive ;)

  243. Ge0rG

    but it's all part of the same problem, and "multi-device sync" is as good a name as anything.

  244. Kev

    It also *might* include highlighting notifications potentially.

  245. Kev

    Although that is strictly distinct and can be worked on separately.

  246. Ge0rG

    Kev: there is some overlap. And some other overlap with push.

  247. Kev

    There is *huge* overlap with push.

  248. Ge0rG

    Except when E2EE is involved.

  249. Kev

    Push is essentially just one instance of highlight/notifications.

  250. Ge0rG

    Well, you might be right on that one.

  251. moparisthebest

    Can xmpp 2 ditch STARTLS also?

  252. Kev

    I think that's roughly orthogonal, isn't it?

  253. Ge0rG

    Kev: except in the current ISR spec

  254. Ge0rG

    where there is a `location` pointer to a direct-TLS server.

  255. moparisthebest

    Kev: well if the goal is to make things quicker no

  256. Kev

    moparisthebest: That isn't the goal of this in general, no.

  257. moparisthebest

    One srv query is better than two, plus TLS goodies like 0rtt , fast start etc etc

  258. moparisthebest

    Or if the goal is to reduce legacy at all

  259. Kev

    Yes, not arguing that going back to 'xmpps' isn't sensible, but I don't see that as part of the same problem.

  260. Kev

    No, reducing legacy isn't an aim in itself.

  261. moparisthebest

    Well like Ge0rG said isr requires direct TLS, if you don't drop STARTLS all new servers need to support both

  262. zinid

    everyone went back to xmpps already, after configuring direct-tls on my server, all my clients automatically switched on it (dino and conversations)

  263. moparisthebest

    Seems like a small beneficial change to me

  264. moparisthebest

    And so I hear gajim 1.0 beta zinid

  265. zinid

    all the more so

  266. Kev

    moparisthebest: We can't drop STARTTLS for as long as we have 6120. Which I've no interest in replacing.

  267. moparisthebest

    ah I thought this was the push to new RFC

  268. moparisthebest

    the new routing rules don't conflict?

  269. zinid

    6120 is okayish, it's 6121 which should be replaced, IMO

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

  271. Kev

    And yes, chunks of 6121 needs overriding.

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

  273. zinid

    I think dialback makes sense, not every admin understands PKIX currently

  274. moparisthebest

    wow then they need to stop being an admin

  275. moparisthebest

    retire, start another career they can do

  276. zinid

    that's rude

  277. Ge0rG

    Potato farming is a thing

  278. moparisthebest

    you don't need to have a full understanding of everything involved in PKIX or anything

  279. zinid

    I kinda agree, but don't want to lose customers 😉

  280. zinid

    moparisthebest, I don't say "full"

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

  282. zinid

    so your solution is to replace admins?

  283. moparisthebest

    I haven't met an admin that couldn't do it

  284. moparisthebest

    if such an admin exists and refuses to learn, yes, replace them

  285. zinid

    moparisthebest, the problem is that XSF cannot replace admins

  286. moparisthebest

    it's getting impossible to run http without https, if it's good enough for http, it's surely good enough for xmpp

  287. zinid


  288. zinid

    how that? I run it without https

  289. moparisthebest

    it's *getting* impossible

  290. zinid

    but not impossible so far

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

  292. moparisthebest

    *and* soon browsers will issue ugly 'insecure' warnings

  293. zinid

    yeah, the dream of cryptobitches

  294. Zash

    I hope you enjoy the future where you must get permission from some authority to host a website.

  295. zinid

    Zash, only a restricted list of authorities 😉

  296. moparisthebest

    you can self-sign just like always

  297. Zash

    Ha, good luck with that

  298. moparisthebest

    just import it into your trusted CA list on every machine 😛

  299. zinid

    moparisthebest, but self-sign doesn't work already

  300. zinid

    also, dialback resolves the issue: you can self-sign

  301. Zash

    Dialback is pretty terrible tho

  302. moparisthebest

    I think dnssec+dane solves the issue without CAs too right?

  303. Ge0rG

    I love how browsers have made self-signed SSL appear less secure than plain-text HTTP.

  304. moparisthebest

    not for you poor .im victims

  305. moparisthebest

    but for normal people 🙂

  306. Zash

    Browsers hate DANE, so good luck with that

  307. moparisthebest

    I meant for xmpp

  308. moparisthebest

    as a dialback alternative

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

  310. Ge0rG

    moparisthebest: but they haven't fixed SRVid certs

  311. moparisthebest

    that's only an xmpp problem though right?

  312. Ge0rG

    moparisthebest: no, it's a non-web problem.

  313. moparisthebest

    what else uses SRV and enforces valid TLS certs?

  314. jonasw

    moparisthebest, I think mumble can do both

  315. Ge0rG

    So how can I test Direct-TLS before activating the SRV records?

  316. moparisthebest

    Ge0rG, openssl s_client ?

  317. Ge0rG

    SRV is used by LDAP, SIP and... *Minecraft*!

  318. moparisthebest

    but I think most don't enforce valid TLS

  319. moparisthebest

    Ge0rG, I think you'd test it like openssl s_client -connect xmpps.conversations.im:443 -servername conversations.im -alpn xmpp-client

  320. Ge0rG

    I think prosody will ignore the alpn part.

  321. moparisthebest

    sslh in front of it might not though

  322. moparisthebest

    -servername and -alpn may not be needed depending on server setup

  323. Ge0rG

    But yeah, got it now. If I don't send a proper stream header, it will fall back to HTTPS

  324. Ge0rG

    _xmpps-client._tcp.yax.im has SRV record 5 1 443 xmpp.yaxim.org.

  325. Ge0rG

    Let's see how it works out.

  326. moparisthebest

    does yaxim (the client) support that now?

  327. Ge0rG

    moparisthebest: no :(

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

  329. moparisthebest

    I need to setup like bad.example.org for some test cases or something, one day

  330. jonasw

    define broken

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

  332. moparisthebest

    or invalid XML would abort the attempts

  333. moparisthebest

    things like that

  334. Ge0rG

    So my server is slowly accepting more and more connections on :443.

  335. moparisthebest

    Ge0rG, how do you have it set up? I can't tell from my end

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

  337. Ge0rG

    moparisthebest: mod_net_multiplex on :443

  338. moparisthebest

    I don't get anything from your server though

  339. Ge0rG

    moparisthebest: give it a valid XML stream

  340. Ge0rG

    It's been enabled for a year, but I never managed to test and add the SRV record.

  341. moparisthebest

    hmm I can't find any docs on that module, didn't know it existed

  342. Flow

    moparisthebest: so an invalid cert should be ignored and the next SRV RR tried?

  343. moparisthebest

    Flow, I think so, why not?

  344. Flow

    moparisthebest, dunno, do browser try a different A/AAAA RR if the cert is invalid?

  345. moparisthebest

    probably not, but those aren't SRV records where you *should* try next

  346. Flow

    well only by priority

  347. Flow

    and it's also debatable if an invalid cert should trigger a fallback

  348. Flow

    but if that's what we want, then xep368 should mention it

  349. moparisthebest

    what about invalid xml ?

  350. moparisthebest

    I actually don't know, it should follow same rules as normal starttls srv fallback I guess

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

  352. Flow

    I never saw such rules ;)

  353. Flow

    well those I saw

  354. moparisthebest

    I guess the debate is what 'fails to connect' means 🙂

  355. moparisthebest

    I would class any errors as a failure and fallback

  356. moparisthebest

    including invalid XML or invalid TLS cert=

  357. Flow

    anyway, SRV fallback on invalid cert would possibly be a good idea to aid cert migration or so

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

  359. jonasw

    moparisthebest, I’m not sure that "try another SRV record" is the appropriate course of action if one SRV records yields invalid XML...

  360. moparisthebest

    why not jonasw ?

  361. jonasw

    I’m just not sure :)

  362. SamWhited

    SRV/TCP connection and the application layer protocol are two different layers of the stack that shouldn't be mixed.

  363. moparisthebest

    if so xep-368 is useless and should be abandoned 😛

  364. Flow

    jonasw, "SRV records yields invalid XML"?

  365. jonasw

    Flow, s/if one SRV records/if a server on a specific SRV record/

  366. jonasw

    moparisthebest, why?

  367. moparisthebest

    try any account on burtrum.org over ipv4 on any client that doesn't implement ALPN (dino for instance)

  368. moparisthebest

    it fails to connect, because if you don't send alpn, you get a non-xml response from nginx

  369. jonasw

    moparisthebest, you should have written that in the XEP

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

  371. jonasw

    clients do not have to set the ALPN. it thus has to work without it.

  372. moparisthebest

    right, I think it's in there

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

  374. moparisthebest

    so I have additional SRV records that don't require ALPN, because I expect clients to fall back 🙂

  375. jonasw

    I think the error modes clients have to expect should be spelt out explicitly

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

  377. jonasw

    I’m pretty sure that bad things™ happen with aioxmpp

  378. jonasw

    and probably no fallback

  379. jonasw

    SamWhited, it does, that’s specified in XEP-0368

  380. SamWhited

    jonasw: what does what?

  381. moparisthebest

    SamWhited, that xep suggests mixing them as if they are one set of SRV records

  382. jonasw

    SamWhited, it is (part of the normal SRV fallback), that’s specified in XEP-0368

  383. Flow

    what jonas said, the xep should mention it, especially since we have evindence that most developers forget about the fallback case(s)

  384. SamWhited

    Oh geeze, I thought that got taken out. That makes no sense and I will be ignoring it.

  385. moparisthebest

    when I wrote it I assumed fallback would just work, I had to make it work in conversations

  386. moparisthebest

    but yea I'm just now noticing clients not handling it well

  387. jonasw

    SamWhited, it’s "just" a SHOULD, but in fact the first point in the rules :)

  388. moparisthebest

    so I agree, that should be in implementation notes now 🙂

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

  390. moparisthebest

    yes it used to be MUST but someone ( ralphm I think) pointed out they might want to JUST query xmpps-client

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

  392. jonasw

    are there DNS libraries which handle SRV logic? ;-)

  393. jonasw

    I had to roll that myself, too

  394. moparisthebest

    most I've seen give you a list, and you have to sort/try them yourself

  395. jonasw


  396. moparisthebest

    but does anyone see harm in falling back in any type of 'non-success' ?

  397. moparisthebest

    or at least, invalid TLS or invalid XML

  398. jonasw


  399. moparisthebest

    like where a connection is not established

  400. jonasw

    authentication failure is probably a bad idea to fall back on

  401. jonasw

    or lack of a (client-)required stream feature

  402. moparisthebest

    yes was going to say not that

  403. Flow

    jonasw: https://github.com/MiniDNS/minidns/blob/master/minidns-hla/src/main/java/de/measite/minidns/hla/ResolverApi.java#L183

  404. moparisthebest

    well, auth

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

  406. moparisthebest

    a lack of client-required stream feature, why not fall back?

  407. moparisthebest

    maybe the next server has what you are looking for?

  408. jonasw

    Flow, I can’t tell from the code whether that does the sorting?

  409. Flow

    jonasw, it does the right thing™

  410. jonasw

    moparisthebest, because the servers are supposed to be identical

  411. moparisthebest

    jonasw, why? where does it say that?

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

  413. Flow

    (so sorting and taking weight into consideration)

  414. jonasw

    Flow, so it returns an iterable of SRV records which I can try in that order?

  415. Flow

    jonasw, yep

  416. jonasw

    Flow, okay

  417. jonasw

    does it select records from the same priority randomly or does it allow you to try multiple of the same priority?

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

  419. Flow

    hmm fallback on invalid XML and cert, yes, but on authentication failure? no…

  420. moparisthebest

    yea I think maybe that would be a sensible place to draw the line

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

  422. moparisthebest

    if you get to authentication, quit, otherwise fallback

  423. Flow

    jonasw, I don't think that you are supposed to try multiple RRs from the same priority

  424. moparisthebest

    jonasw, why, maybe they run ejabberd on one server and prosody on the other and have some home-grown thing to connect them?

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

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

  427. Flow

    uhh, a heterogeneous xmpp server cluster, want!

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

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

  430. moparisthebest

    that's at least how conversations works

  431. jonasw

    the SRV code is over at that point

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

  433. moparisthebest

    then you should rework that 😛

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

  435. jonasw

    SamWhited, I think your dial does too much

  436. moparisthebest

    I don't see anywhere where SRV says fallback only in the event of TCP not connecting

  437. jonasw

    users may have legitimate reasons to override the SRV lookup

  438. jonasw

    (e.g. during testing)

  439. moparisthebest

    not even rfc6120

  440. jonasw

    so having those two functions separate is definitely required

  441. moparisthebest

    it uses a vague 'fails to connect' language

  442. jonasw

    and once you’ve got there, you can properly decouple the two (srv lookup and dial) and provide a third which mixes both

  443. jonasw

    (i.e. iterates over the records and tries them until either success or fatal error, where not every error is fatal)

  444. moparisthebest

    in fact SRV couldn't say that, because it supports things other than TCP that don't have a defined 'connection'

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

  446. moparisthebest

    but regardless, sounds like we could use some good on-list discussion about proper SRV fallback behavior

  447. jonasw

    moparisthebest, that sounds sensible

  448. moparisthebest

    and then put some if not all of it in xep-368

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

  450. moparisthebest

    I guess waiting so long before final turns out to be a good idea 🙂

  451. jonasw

    SamWhited, ah I see

  452. moparisthebest

    SamWhited, wouldn't a lib like that take a username+password ?

  453. moparisthebest

    in which case it'd know if it reached auth yet

  454. SamWhited

    moparisthebest: no, it's just dialing TCP connections, it doesn't know anything about XMPP

  455. moparisthebest

    oh, well, that's odd

  456. jonasw

    I tend to agree

  457. moparisthebest

    especially for direct TLS

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

  459. jonasw

    yeah, I don’t think that’s good

  460. SamWhited

    Why not?

  461. Flow

    define "valid connection"

  462. SamWhited

    "a tcp socket was established"

  463. moparisthebest

    so it doesn't check TLS cert either?

  464. Flow

    there you have your issue

  465. SamWhited

    I can't remember, it might do TLS

  466. jonasw

    SamWhited, the server could be telling you that it is out of capacity currently

  467. moparisthebest

    a xmpp connection is in my opinion a negotiated stream over a valid TLS connection

  468. moparisthebest

    so like, after you get that far, maybe don't fallback

  469. moparisthebest

    but before you should absolutely fallback

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

  471. moparisthebest

    Flow, yea I fired up dino and it failed to connect 😛

  472. Flow

    ahh because of alpn

  473. moparisthebest

    same with conversations with my initial patch, but I was already deep in that code so I fixed it

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

  475. moparisthebest

    SamWhited, SRV has nothing to do with TCP and therefore nothing to do with connections

  476. moparisthebest

    if you want to go up that high

  477. moparisthebest

    imagine a _udp SRV record, what a successfull connection entails is entirely application layer

  478. moparisthebest

    same here imho

  479. Flow

    yep, it feels like SRV records to be more at the application layer

  480. SamWhited

    Yah, I actually have some separation there too but it's not relavant for this discussion

  481. SamWhited

    But the retrying is just about dialing TCP sockets, it's definitely not application layer

  482. jonasw

    SamWhited, it could also simply timeout after accepting the TCP connection

  483. moparisthebest

    still disagree

  484. jonasw

    because the server is massively overloaded

  485. SamWhited

    Or rather, not application protocol layer. It has nothing to do with XMPP and I don't want it to know about XMPP.

  486. jonasw

    and you should be trying the next one

  487. jonasw

    you can’t tell that purely from the TCP layer

  488. moparisthebest

    then how do _udp SRV records work?

  489. jonasw

    SamWhited, make XMPP know about the SRV records, not the SRV records know about XMPP.

  490. SamWhited

    These aren't udp SRV records, but fair enough, I don't know

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

  492. jonasw

    SamWhited, not necessarily

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

  494. moparisthebest

    I don't think either stance is necessarily wrong or right, just needs to be agreed upon and written down and followed 🙂

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

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

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

  498. moparisthebest

    well then your library doesn't work with my server

  499. moparisthebest

    which I guess is fine, unless my server happens to be huge like conversations.im or something

  500. jonasw

    SamWhited, it is a compatibility issue with XEP-0368 servers which require ALPN.

  501. Flow

    the xep should at least recommend fallback on invalid cert/xml

  502. moparisthebest

    I have to patch 368 support out of dino to use it currently, for example

  503. jonasw

    moparisthebest, would you care to fire an aioxmpp exmaple against your server?

  504. moparisthebest

    as added fun, my server does not require alpn over ipv6 😛 (which, having unlimited addresses, I multiplex that way instead of sslh...)

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

  506. moparisthebest

    jonasw, I can make you a test account if you like

  507. jonasw

    moparisthebest, EBUSY currently

  508. jonasw

    and I’ll likely forget about it :/

  509. 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)."

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

  511. moparisthebest

    which obviously expects clients to fallback when hit with invalid xml or whatever

  512. jonasw

    moparisthebest, I don’t find that obvious tbh :)

  513. jonasw

    but that may simply be my lack of domain knowledge

  514. moparisthebest

    jonasw, well obvious to me, but in hindsight, I fully agree with you 😛

  515. moparisthebest

    again, no one ever accused me of being an english wizard 😛

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

  517. moparisthebest

    well, or falling back at all

  518. moparisthebest

    I think my current SRV setup is 443 first (which requires alpn or you get invalid xml) and then 5223 next

  519. moparisthebest

    and then 5222/starttls

  520. moparisthebest

    if we decide fallback stops at tcp connect I'd need to move priority to 5223 first, 5222 second, 443 last

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

  522. moparisthebest

    you could, only http2 browsers will do it though

  523. SamWhited

    ahh, right

  524. moparisthebest

    which is most newish/secure ones for sure

  525. SamWhited

    Will they do it for http/1.1 as well though, or just http/2?

  526. moparisthebest

    I think they do it for both

  527. moparisthebest

    I know http/1.1 is defined, not sure if I've ever actually checked honestly

  528. moparisthebest

    also this would need updated https://wiki.xmpp.org/web/Tech_pages/XEP-0368

  529. moparisthebest

    in hindsight I fully assumed fallback would happen regardless 🙂

  530. zinid

    moparisthebest, "prosody legacy port"

  531. moparisthebest

    zinid, yea prosody devs need to alias that to 'direct_tls_port' 😛

  532. zinid

    moparisthebest, I think the article shouldn't assume the server name

  533. moparisthebest

    zinid, what does ejabberd call it? I assume something similar

  534. zinid

    just replace prosody with 'xmpp server'

  535. zinid

    the text is valid for all servers

  536. moparisthebest

    well I wanted to be explicit, I'll put 'prosody legacy_ssl_port' or ejabberd whatever_that_calls_it

  537. zinid


  538. zinid

    what if I use haproxy?

  539. moparisthebest

    it's not a spec it's an example

  540. zinid

    ok, so I will copy it, replace names and submit to the wiki?

  541. zinid

    because I cannot refer to the article in this version

  542. moparisthebest

    sure if it's useful 😛

  543. moparisthebest

    it's more meant for people who followed a tutorial to set up prosody or something

  544. moparisthebest

    people who can read specs probably don't need it

  545. zinid

    as I said above, sslh config is the same for *any* xmpp/imap/http server

  546. moparisthebest

    yes, but if I say like 'xmpp server direct tls port' then you have to search docs to discover what that's named

  547. moparisthebest

    so I'd like to say xmpp server direct tls port (prosody legacy_ssl_ports, ejabberd whatever_its_called)

  548. zinid


  549. moparisthebest

    and then https port (nginx, apache)

  550. moparisthebest

    or whatever, in the comments

  551. moparisthebest

    I thought it was pretty obvious you didn't *have* to use prosody

  552. moparisthebest

    but feel free to update the wiki with ejabberd name or whatever too, it's a wiki

  553. zinid

    nah, it is better to rename the page to prosody-nginx-openssh-dovecot related configuration

  554. zinid

    then I'm fine with it

  555. moparisthebest


  556. zinid

    anyway, I don't remember my account credentials, so

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

  558. zinid

    moparisthebest, nice logic

  559. zinid

    moparisthebest, why didn't you put 'prosody' everywhere in xep-0368 instead of 'xmpp server'?

  560. zinid

    if someone can't figure that, oh well...

  561. moparisthebest

    because it's a spec, not a friendly hand-holdy example 😛

  562. zinid

    but your logic still applies

  563. moparisthebest

    it's like a tutorial or an example, that's all

  564. moparisthebest

    make it too generic and it gets useless, like I said, I'm fine with adding what ejabberd calls it in there

  565. zinid

    ejabberd doesn't call anything related to this

  566. zinid

    listen: - port: 5223 module: ejabberd_c2s tls: true ...

  567. zinid

    not sure what should be called here and why

  568. moparisthebest

    and that implied direct tls ?

  569. moparisthebest


  570. zinid

    yes, and `starttls: true` implies starttls, who would have thought that 🙂

  571. moparisthebest

    do you have to specify one or the other?

  572. zinid

    no, if you don't need (start)tls at all

  573. zinid

    but you cannot specify both

  574. moparisthebest

    if you don't does it imply starttls ?

  575. zinid

    no, it implies no starttls

  576. zinid

    plain connection

  577. moparisthebest

    check that edit zinid https://wiki.xmpp.org/web/Tech_pages/XEP-0368 better?

  578. zinid

    yes, much better, thanks

  579. moparisthebest

    np, thanks for ejabberd config info!

  580. zinid

    does dino support ALPN?

  581. moparisthebest

    zinid: not currently that's how I discovered the broken fallback

  582. zinid

    moparisthebest: I see