Dave CridlandJust submitted one Internet Draft, plus two ProtoXEPs, covering adding TOTP-based 2FA to XMPP.
Dave Cridlandedhelas, You might be interested in that, as I recall.
edhelaslink ?
jonaswtwo(!) protoxeps
jonaswyou want me to fail my exams!!!k
jonaswI may take care of them tonight
Dave Cridlandjonasw, No problem.
Dave Cridlandjonasw, As in, no rush - not that your exams aren't a problem.
jonaswI understood, and also I was joking :)
suzyohas joined
Dave Cridlandedhelas, 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.
jjrhhas left
Dave Cridlandedhelas, The Internet Draft is here: https://datatracker.ietf.org/doc/draft-cridland-kitten-clientkey/
Dave Cridlandedhelas, 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.
Dave Cridlandedhelas, It demands a few supporting functions from the containing protocol, which is the other ProtoXEP.
edhelasokay good
edhelaswill have a look at it asap
Ge0rGDave Cridland: how often is it supposed to ask for TOTP veriifcation?
Dave CridlandGe0rG, Without the CLIENT-KEY mechanism? Every time.
Ge0rGDave Cridland: this question is generally interesting to me in the context of long-living TCP sessions, but also for 0198 and ISR
Dave CridlandGe0rG, That would, of course, be nuts.
Ge0rGDave Cridland: and with client key?
Dave CridlandGe0rG, With CLIENT-KEY, it wouldn't. But CLIENT-KEY has expiry and things built in, to force users to reauthenticate.
jjrhhas left
jonaswDave Cridland, Builds/xeps/inbox/totp-2fa.xml: not well-formed (invalid token): line 99, column 61
danielhas left
danielhas joined
Dave Cridlandjonasw, Yeah, the ABNF. On it...
Ge0rGDave Cridland: will CLIENT-KEY expiry close the session, or require an in-session reauth?
Dave CridlandNeither.
jerehas joined
Ge0rGSo if I have a good network, I can stay logged in forever?
jonaswat some point, the servers certificate will expire and your client will of course disconnect you :)
Dave CridlandGe0rG, Sure. I imagine if a server admin thought this was a problem they could put in a session expiry.
Ge0rGjonasw: I LOLed.
jonaswsleekxmpp actually does that.
KevPresumably if there is an issue with authentication of long-lived sessions, this goes beyond the tokens, and would apply to all sessions.
KevSeems orthogonal to this.
ralphmhas joined
Dave Cridlandjonasw, Incorrectly, I'd suggest. The certificate defines how long the identity assertion is warranted for, not how long the identity might last.
jjrhhas left
Dave Cridlandjonasw, Travis is back doing its magic on an update.
jonaswDave Cridland, not sure. If I actually managed to steal a certificate, long-running sessions would fall for me longer than needed.
Dave Cridlandjonasw, Quite possibly. But that's not what the certificate expiry is for.
jonaswso 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.
jonaswah okay, but you could also assume that the identity was then correctly asserted when you connected and don’t need to care anymore.
jonaswDave Cridland, built for website in progress, ETA 2h
jjrhhas left
mathieuiiDave Cridland, maybe the namespace would be better as urn:xmpp:totp:0? "mfa" is a bit broader than TOTP
Dave Cridlandhas left
uchas left
uchas joined
jonaswSteve 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 :)
Steve Killeoopps
Steve Killeand thanks
jonaswbuild in progress, ETA ≤ 2h
mathieuiione of my concerns is that most services offering TOTP have "recovery codes" the user can use when they lose their secret
jjrhhas left
Ge0rGmathieuii: is that a sentiment about lack of security of 2FA implementations?
mathieuiinot security, rather improved security leading to account locking
Ge0rGit should be really hard but not impossible to recover from a 2FA loss
mathieuiiyes
mathieuiiwell, currently there’s no standard for password recovery either, so that’s consistent at least
Ge0rGI'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.
jonaswisn’t that the whole idea of ISR+0198?
Ge0rGjonasw: yes
Ge0rGjonasw: but consider a pre-ISR pre-CLIENT-KEY world, where the user enters a TOTP token value on each login.
Ge0rGhow long should that authenticated session be considered valid? Until the expiry of the server SSL cert?
Flowhas joined
Ge0rGHi Flow! Were just talking about you ;)
Flowwhat a coincidence :)
MattJIt's similar to the question of whether s2s connections should close when the cert that was used to authenticate them expires
Ge0rGI tend to agree with Kev that it's somewhat orthogonal to SSL cert lifetime, though.
Ge0rGThe question still remains, how long and under which conditions a session should be considered valid.
Ge0rGTLS session reuse also comes to mind in this context.
Ge0rGBut I'm not very inclined to outsource the reauth of a layer 7 client session to TLS.
Ge0rGI 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.
ZashDo you stop being you when your cert expires?
mathieuiiyes
Ge0rGZash: you can't know for sure.
ralphmhas joined
Dave Cridlandmathieuii, Oh, we did account unlocking too. Do we want a XEP on it? We did that as a SASL mechanism based around emailed codes.
Ge0rGWhy must everything be a SASL mechanism?
Dave CridlandGe0rG, Because it's an authentication, and that's where authentications live in XMPP.
Ge0rGSo it requires to re-login to enter the unlock code?
Dave CridlandGe0rG, No, an unlock code *is* an authentication.
Dave Cridlandhas left
Dave Cridlandhas left
Ge0rGDave Cridland: oh, maybe I have a different understanding of that term then.
Dave CridlandGe0rG, 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.
Ge0rGDave 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.
Ge0rGDave Cridland: what you are describing sounds like a password|credentials reset mechanism, which of course _is_ an authentication
Dave CridlandGe0rG, Ah, I see. No, I was meaning the codes to unlock/recover an account when the TOTP is lost.
Ge0rGso maybe "account recovery" would be a better term, then
Dave CridlandGe0rG, Yeah, probably.
Ge0rGmarc 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.
Ge0rGThough I must admit I don't particularly like that approach.
Ge0rGTechnically 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.
Ge0rGThis is pretty similar to account recovery, though.
marcGe0rG, didn't follow the discussion but the account doesn't exists in my approach
Ge0rGmarc: how do you ensure that nobody else registers the same account?
marcGe0rG, checking :)
Ge0rGmarc: this answer is insufficient.
marcGe0rG, for user invitation you don't have the problem
marcfor account creation the account name is reserved
Holgerhas left
Ge0rGmarc: the easiest way to reserve an account name is to regiser that account, isn't it?
marcGe0rG, no, because the invitation may expire
marcaccount creation
Ge0rGAh, right.
marcPuh, I expected a big discussion :D
marcI should write this down right now...
marcGe0rG, btw, we still need the ibr=true query parameter, right?
Ge0rGmarc: yes
marcokay, good
jonaswmarc, how’s your progress on submitting the protoxep?
marcjonasw, what does submitting mean? Official submitting or publishing it on my web server?
jonaswmarc, the former
jonaswa PR to the xeps repo
GuusFor those that are interested: I've send out the summit / fosdem hotel group discount details and registration form to the summit mailing list.
vanitasvitaehas left
marcI don't know how a protoXEP should look like before submitting it
jonaswmarc, 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.
vanitasvitaehas joined
vanitasvitaehas left
Ge0rGThe end is nigh! https://techcrunch.com/2018/01/08/telegram-open-network/
mathieuii"Durov’s idea is to launch an entirely new blockchain" send help
marcjonasw, I need a better motivation and probably some other stuff is missing
marcjonasw, I try to push it to my webserver tomorrow
marcSo you guys can look at it, give some feedback before pushing it to xsf repo
Ge0rGmarc: I can help you writing some sections. Just give me a git 😜
jonaswI feel that this feedback should happen in official protoxep or even experimental state.
Ge0rGI've submitted the astonishing number of 1 xeps already.
marcjonasw, I don't think so because I expect that there will be some really basic mistakes etc.
jonaswmarc, don’t worry about that
marcGe0rG, will give you a Git tomorrow I think
jonaswthis will help ironing out those mistakes. if it is too bad for Experimental status (which I don’t think), you can still refine it
Ge0rGmarc: 👍🏽
hanneshas joined
ralphmhas joined
Dave Cridlandhas left
Dave Cridlandhas left
danielhas left
danielhas joined
Dave Cridlandjonasw, +1 to that.
Dave CridlandOr more generally, if it's worth working on, it's worth submitting.
zinidGe0rG,
> Durov and his brother Nikolai Durov, a mathematical genius
I lol'd. Who wrote this?
Ge0rGzinid: probably a journalistics genius.
ralphmhas joined
Dave CridlandMan, that's one seriously transparent Poniz scheme.✎
Dave CridlandMan, that's one seriously transparent Ponzi scheme. ✏
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.
zinidof course BFT is slower, especially the one with timeouts
Ge0rGNow stop bashing the Durovs and let's focus on our own ICO! JabberCoin!
danielhas left
danielhas joined
Ge0rGI even have a motto for it already: "The brightest light [or lamp?] in crypto moneys!"
intosiXeptoCoin?
moparisthebestintroducing, JabberCoin! (5 minutes later, sued to death by cisco...)
zinidthere is already a shitcoin
Ge0rGOh, right. That trademark thing.
Ge0rGzinid: so we make a JIDcoin
moparisthebestzinid, a ? like only 1 ?
Dave Cridlandmoparisthebest, The XSF can license us, though.
Ge0rGDave Cridland: I'm not sure we can have something that starts with "jabber" and is a commercial entity from the XSF.
Ge0rGzinid: to make a public statement about blocking and shaming abandoned servers.
MattJTo reach a long list of good spam-free servers
moparisthebestzinid: get major server admins to agree?
zinidok, and what practical implications?
jonaswGe0rG, where did you even advertise that?
Ge0rGjonasw: the manifesto? I asked some server admins so far
MattJzinid, if you're not on the list, people may limit/filter/block traffic from your server
moparisthebestjonasw agreed to operate an rbl right? :)
zinidMattJ, nice 🙂
zinidbut what if I don't run a public server? I'll be blocked too?
MattJIf you don't originate spam, I doubt it :)
jonaswmoparisthebest, I did
Ge0rGXMPP spam is Russian. zinid is Russian. Might get blocked by accident.
jonasw:>
jonaswblock ru TLD, be done with spam ;-)
Ge0rGjonasw: no, they are using IBR servers all over the world. Need to block cyrillic letters instead.
jonaswI wasn’t serious anyways
moparisthebestjonasw, 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 ...
jonaswmoparisthebest, yeah, dns it’ll be
jonaswI’ll also run this on a dedicated machine. I expect some trouble out of it.
Ge0rGjonasw: you should run it on a dedicated uplink then.
jonaswGe0rG, that’s my ISPs job :>
Ge0rGin a dedicated data center.
Ge0rGon a dedicated Internet.
jonaswthey have DDoS-protection
jonaswat least they advertise it
moparisthebestyou could just let a big DNS provider take care of it for you
jonaswmoparisthebest, thought of that, but I wonder how well updates would work with that
moparisthebestcloudflare, hurricane electric, I'm sure there are other free ones
moparisthebestcloudflare has an API at least
jonaswI don’t like cloudflare
Ge0rGyou could run a hidden primary and have some provider run the secondaries.
moparisthebestjonasw, another, yep what Ge0rG said
jonaswGe0rG, that sounds like a good plan.
danielhas left
danielhas joined
zinidGe0rG, do you have s2s dialback enabled on yax.im?
jerehas joined
moparisthebestjonasw, 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
moparisthebestonly ones I could find that support everything I needed, dnssec and such too
Ge0rGzinid: yes I do
danielhas left
danielhas joined
Ge0rGmoparisthebest: do you have stats from them?
Ge0rGis looking for a new secondary for some zones
jonaswGe0rG, I’ll be happy to :)
moparisthebestGe0rG, what kind of stats?
jonaswbut no guarantees :)
danielhas left
danielhas joined
Ge0rGmoparisthebest: reliability, speed of zone propagation, such things.
Ge0rGhas been using the freendns dyndns service for some 15 years now
moparisthebestGe0rG, so 2 of the 3 providers support the push thing so zone propagation is instant
jonaswunfortunately, cloudflare thinks that DNS secondary is an enterprise solution :/
moparisthebestI want to say puck.nether.net is the one that takes up to like 10 minutes
moparisthebestbut 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)
Ge0rGmoparisthebest: great!
moparisthebestwhich, is good enough for me, that's why I have 3 different providers and 4 servers 😛
moparisthebestthe likliehood all 3 are ever down seems slim
jonaswanyways, gotta go
danielhas left
danielhas joined
danielhas left
danielhas joined
danielhas left
danielhas joined
Ge0rGMonal. Will create an individual notification for each message in a conversation. Won't delete any if you respond from the PC.
vanitasvitaehas joined
ralphmhas joined
moparisthebestGe0rG, this is a good one too (multicast) but no dnssec 😢 https://system-ns.com/services/secondary
danielhas left
danielhas joined
moparisthebestin 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
Ge0rGmoparisthebest: not that I would care about DNSSEC, with the sad .IM situation
moparisthebestyea, what happened with that?
moparisthebestlast I heard they said they would add support, which had to have been years ago
Ge0rGmoparisthebest: really? Last thing I heard was "not on the agenda"
Dave Cridlandhas left
Dave Cridlandhas left
Ge0rGAnd that was when DLV was still a thing
Alexhas joined
moparisthebestI thought someone from here contacted them
Ge0rGmoparisthebest: I did
Ge0rGmoparisthebest: last time in 2015, "Unfortunately as per our previous correspondence there is still no movement regarding your query."
moparisthebestCurrently .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.
moparisthebestwonder if that email still exists, also, you should bug them again Ge0rG 😛
Ge0rGI've lost my hope in DNSSEC
moparisthebestnowadays I don't buy domains unless they have full dnssec support 😢
moparisthebestat least all the new ones are required to have it
marchas left
suzyohas joined
lskdjfhas joined
danielhas left
efrithas left
marchas left
danielhas joined
Kevhas left
vanitasvitaehas left
georghas joined
Ge0rGSigh. Clients that ignore the bookmarked nickname for 300.
Ge0rGAnd then a gazillion popups from ChatSecure. Looks like it does MUC MAM too, now.
ralphmhas joined
vanitasvitaehas joined
georghas left
vanitasvitaehas left
efrithas joined
vanitasvitaehas joined
Ge0rGhas joined
suzyohas joined
suzyohas joined
Dave Cridlandhas left
Dave Cridlandhas left
danielhas left
danielhas joined
@Alacerhas left
blablahas left
Syndacehas joined
Syndacehas left
Syndacehas joined
tuxhas joined
danielhas left
danielhas joined
Dave Cridlandhas left
suzyohas joined
suzyohas joined
jerehas joined
KevGe0rG: 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.
jerehas joined
ralphmhas joined
Ge0rGKev: I think the most probable outcome is me tele-participating.
Ge0rGEven though I always only get 30% through WebEx :(
Ge0rGKev: have you written down any proto-XEP yet?
KevI was hoping to get the Informational thing submitted before the summit, but that's looking very tight now. We'll see.
KevRight, I was just typing that :)
Ge0rGKev: Also, I think last time we limited the scope from XMPP2 down to message routing 2
KevI think we need to cover more than just message routing 2, to be able to advance various things.
danielhas left
danielhas joined
Ge0rGKev: various things are good, right?
KevI don't know which of the possible meanings of that you intend.
Ge0rGKev: I hope I can take the time to actually do my presentation; maybe that would be a good prequel to your XMPP2?
Ge0rGKev: 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.
KevMulti-device sync.
KevOf which message routing is a subset, I think.
KevI think bind2/sasl2 are part of this too, although maybe they don't currently need discussion.
Ge0rGKev: I'd consider multi-device sync as part of the message routing problem.
KevNo, definitely the other way around :)
KevBecause sync involves both history fetching and read-state synchronising, neither of which is routing :)
Ge0rGit's routing to the archive and from the archive ;)
Ge0rGbut it's all part of the same problem, and "multi-device sync" is as good a name as anything.
KevIt also *might* include highlighting notifications potentially.
KevAlthough that is strictly distinct and can be worked on separately.
Ge0rGKev: there is some overlap. And some other overlap with push.
KevThere is *huge* overlap with push.
Ge0rGExcept when E2EE is involved.
KevPush is essentially just one instance of highlight/notifications.
Ge0rGWell, you might be right on that one.
moparisthebestCan xmpp 2 ditch STARTLS also?
KevI think that's roughly orthogonal, isn't it?
Ge0rGKev: except in the current ISR spec
Ge0rGwhere there is a `location` pointer to a direct-TLS server.
moparisthebestKev: well if the goal is to make things quicker no
Kevmoparisthebest: That isn't the goal of this in general, no.
moparisthebestOne srv query is better than two, plus TLS goodies like 0rtt , fast start etc etc
moparisthebestOr if the goal is to reduce legacy at all
KevYes, not arguing that going back to 'xmpps' isn't sensible, but I don't see that as part of the same problem.
KevNo, reducing legacy isn't an aim in itself.
moparisthebestWell like Ge0rG said isr requires direct TLS, if you don't drop STARTLS all new servers need to support both
zinideveryone went back to xmpps already, after configuring direct-tls on my server, all my clients automatically switched on it (dino and conversations)
moparisthebestSeems like a small beneficial change to me
bearhas left
moparisthebestAnd so I hear gajim 1.0 beta zinid
zinidall the more so
Guushas left
Kevmoparisthebest: We can't drop STARTTLS for as long as we have 6120. Which I've no interest in replacing.
bearhas joined
moparisthebestah I thought this was the push to new RFC
moparisthebestthe new routing rules don't conflict?
tuxhas joined
zinid6120 is okayish, it's 6121 which should be replaced, IMO
zinidhas left
KevI 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.
KevAnd yes, chunks of 6121 needs overriding.
jjrhhas left
Guushas left
Dave Cridlandhas left
moparisthebestthen 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
@Alacerhas left
Dave Cridlandhas left
zinidI think dialback makes sense, not every admin understands PKIX currently
moparisthebestwow then they need to stop being an admin
moparisthebestretire, start another career they can do
zinidthat's rude
Ge0rGPotato farming is a thing
moparisthebestyou don't need to have a full understanding of everything involved in PKIX or anything
zinidI kinda agree, but don't want to lose customers 😉
zinidmoparisthebest, I don't say "full"
moparisthebestbut 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
zinidso your solution is to replace admins?
efrithas left
moparisthebestI haven't met an admin that couldn't do it
moparisthebestif such an admin exists and refuses to learn, yes, replace them
zinidmoparisthebest, the problem is that XSF cannot replace admins
ralphmhas left
moparisthebestit's getting impossible to run http without https, if it's good enough for http, it's surely good enough for xmpp
zinidimpossible?
zinidhow that? I run it without https
moparisthebestit's *getting* impossible
zinidbut not impossible so far
moparisthebestyou are missing out on all the new features, and are guaranteed to never get new features (new compression, like brotli, http2, etc etc)
moparisthebest*and* soon browsers will issue ugly 'insecure' warnings
zinidyeah, the dream of cryptobitches
ZashI hope you enjoy the future where you must get permission from some authority to host a website.
zinidZash, only a restricted list of authorities 😉
@Alacerhas joined
moparisthebestyou can self-sign just like always
ZashHa, good luck with that
moparisthebestjust import it into your trusted CA list on every machine 😛
zinidmoparisthebest, but self-sign doesn't work already
zinidalso, dialback resolves the issue: you can self-sign
ZashDialback is pretty terrible tho
moparisthebestI think dnssec+dane solves the issue without CAs too right?
Ge0rGI love how browsers have made self-signed SSL appear less secure than plain-text HTTP.
moparisthebestnot for you poor .im victims
moparisthebestbut for normal people 🙂
ZashBrowsers hate DANE, so good luck with that
moparisthebestI meant for xmpp
moparisthebestas a dialback alternative
Zashhas left
marchas joined
Steve Killehas left
Steve Killehas left
jjrhhas left
jjrhhas left
Zashhas left
Dave Cridlandhas left
hanneshas joined
moparisthebestGe0rG, 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
Steve Killehas joined
Ge0rGmoparisthebest: but they haven't fixed SRVid certs
moparisthebestthat's only an xmpp problem though right?
Ge0rGmoparisthebest: no, it's a non-web problem.
moparisthebestwhat else uses SRV and enforces valid TLS certs?
jonaswmoparisthebest, I think mumble can do both
Dave Cridlandhas left
Dave Cridlandhas left
Ge0rGSo how can I test Direct-TLS before activating the SRV records?
moparisthebestGe0rG, openssl s_client ?
Ge0rGSRV is used by LDAP, SIP and... *Minecraft*!
moparisthebestbut I think most don't enforce valid TLS
jjrhhas left
jjrhhas left
moparisthebestGe0rG, I think you'd test it like openssl s_client -connect xmpps.conversations.im:443 -servername conversations.im -alpn xmpp-client
jjrhhas left
Dave Cridlandhas left
Dave Cridlandhas left
marchas left
Ge0rGI think prosody will ignore the alpn part.
jjrhhas left
uchas joined
jjrhhas left
moparisthebestsslh in front of it might not though
moparisthebest-servername and -alpn may not be needed depending on server setup
Ge0rGBut yeah, got it now. If I don't send a proper stream header, it will fall back to HTTPS
jjrhhas left
Ge0rG_xmpps-client._tcp.yax.im has SRV record 5 1 443 xmpp.yaxim.org.
Ge0rGLet's see how it works out.
moparisthebestdoes yaxim (the client) support that now?
jjrhhas left
georghas joined
Ge0rGmoparisthebest: no :(
georghas left
jjrhhas left
moparisthebestwell 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 🙂
moparisthebestI need to setup like bad.example.org for some test cases or something, one day
Syndacehas left
uchas joined
ralphmhas joined
jjrhhas left
jonaswdefine broken
Zashhas left
Syndacehas joined
moparisthebestjonasw, 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
moparisthebestor invalid XML would abort the attempts
moparisthebestthings like that
Ge0rGSo my server is slowly accepting more and more connections on :443.
Syndacehas left
Syndacehas joined
moparisthebestGe0rG, how do you have it set up? I can't tell from my end
moparisthebestusually 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 🙂
Ge0rGmoparisthebest: mod_net_multiplex on :443
moparisthebestI don't get anything from your server though
Ge0rGmoparisthebest: give it a valid XML stream
Ge0rGIt's been enabled for a year, but I never managed to test and add the SRV record.
Syndacehas left
Syndacehas joined
jjrhhas left
moparisthebesthmm I can't find any docs on that module, didn't know it existed
Flowmoparisthebest: so an invalid cert should be ignored and the next SRV RR tried?
moparisthebestFlow, I think so, why not?
jjrhhas left
Flowmoparisthebest, dunno, do browser try a different A/AAAA RR if the cert is invalid?
moparisthebestprobably not, but those aren't SRV records where you *should* try next
Flowwell only by priority
Flowand it's also debatable if an invalid cert should trigger a fallback
Flowbut if that's what we want, then xep368 should mention it
moparisthebestwhat about invalid xml ?
moparisthebestI actually don't know, it should follow same rules as normal starttls srv fallback I guess
moparisthebesthttps://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."
FlowI never saw such rules ;)
Flowwell those I saw
moparisthebestI guess the debate is what 'fails to connect' means 🙂
moparisthebestI would class any errors as a failure and fallback
moparisthebestincluding invalid XML or invalid TLS cert=
Flowanyway, SRV fallback on invalid cert would possibly be a good idea to aid cert migration or so
SamWhitedI 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.
jonaswmoparisthebest, I’m not sure that "try another SRV record" is the appropriate course of action if one SRV records yields invalid XML...
moparisthebestwhy not jonasw ?
jonaswI’m just not sure :)
SamWhitedSRV/TCP connection and the application layer protocol are two different layers of the stack that shouldn't be mixed.
moparisthebestif so xep-368 is useless and should be abandoned 😛
Flowjonasw, "SRV records yields invalid XML"?
jonaswFlow, s/if one SRV records/if a server on a specific SRV record/
jonaswmoparisthebest, why?
moparisthebesttry any account on burtrum.org over ipv4 on any client that doesn't implement ALPN (dino for instance)
moparisthebestit fails to connect, because if you don't send alpn, you get a non-xml response from nginx
jonaswmoparisthebest, you should have written that in the XEP
FlowI'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?
jonaswclients do not have to set the ALPN. it thus has to work without it.
moparisthebestright, I think it's in there
moparisthebestServer 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).
moparisthebestso I have additional SRV records that don't require ALPN, because I expect clients to fall back 🙂
jonaswI think the error modes clients have to expect should be spelt out explicitly
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.
jonaswI’m pretty sure that bad things™ happen with aioxmpp
jonaswand probably no fallback
jonaswSamWhited, it does, that’s specified in XEP-0368✎
SamWhitedjonasw: what does what?
moparisthebestSamWhited, that xep suggests mixing them as if they are one set of SRV records
jonaswSamWhited, it is (part of the normal SRV fallback), that’s specified in XEP-0368 ✏
Flowwhat jonas said, the xep should mention it, especially since we have evindence that most developers forget about the fallback case(s)
SamWhitedOh geeze, I thought that got taken out. That makes no sense and I will be ignoring it.
moparisthebestwhen I wrote it I assumed fallback would just work, I had to make it work in conversations
moparisthebestbut yea I'm just now noticing clients not handling it well
jonaswSamWhited, it’s "just" a SHOULD, but in fact the first point in the rules :)
moparisthebestso I agree, that should be in implementation notes now 🙂
Dave Cridlandhas left
jonaswmoparisthebest, 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
moparisthebestyes it used to be MUST but someone ( ralphm I think) pointed out they might want to JUST query xmpps-client
SamWhitedI 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)
jonasware there DNS libraries which handle SRV logic? ;-)
jonaswI had to roll that myself, too
moparisthebestmost I've seen give you a list, and you have to sort/try them yourself
jonaswthat
moparisthebestbut does anyone see harm in falling back in any type of 'non-success' ?
moparisthebestor at least, invalid TLS or invalid XML
jonaswyes.
moparisthebestlike where a connection is not established
jonaswauthentication failure is probably a bad idea to fall back on
jonaswor lack of a (client-)required stream feature
SamWhitedYah, 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.
moparisthebesta lack of client-required stream feature, why not fall back?
moparisthebestmaybe the next server has what you are looking for?
jonaswFlow, I can’t tell from the code whether that does the sorting?
Flowjonasw, it does the right thing™
jonaswmoparisthebest, because the servers are supposed to be identical
moparisthebestjonasw, why? where does it say that?
SamWhitedOr, at best, just make development *much* harder since you won't be able to separate your XMPP stuff from your SRV/DNS stuff.
Flow(so sorting and taking weight into consideration)
jonaswFlow, so it returns an iterable of SRV records which I can try in that order?
Flowjonasw, yep
jonaswFlow, okay
jonaswdoes it select records from the same priority randomly or does it allow you to try multiple of the same priority?
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)
Flowhmm fallback on invalid XML and cert, yes, but on authentication failure? no…
jjrhhas left
moparisthebestyea I think maybe that would be a sensible place to draw the line
jonaswmoparisthebest, 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
moparisthebestif you get to authentication, quit, otherwise fallback
Flowjonasw, I don't think that you are supposed to try multiple RRs from the same priority
moparisthebestjonasw, why, maybe they run ejabberd on one server and prosody on the other and have some home-grown thing to connect them?
SamWhitedHow 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
valohas joined
jonaswsure 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.
Flowuhh, a heterogeneous xmpp server cluster, want!
moparisthebestSamWhited, 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?
jonaswSamWhited, 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)
moparisthebestthat's at least how conversations works
jonaswthe SRV code is over at that point
SamWhitedmoparisthebest: 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)
moparisthebestthen you should rework that 😛
SamWhitedMy 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.
jonaswSamWhited, I think your dial does too much
moparisthebestI don't see anywhere where SRV says fallback only in the event of TCP not connecting
jonaswusers may have legitimate reasons to override the SRV lookup
jonasw(e.g. during testing)
moparisthebestnot even rfc6120
jonaswso having those two functions separate is definitely required
moparisthebestit uses a vague 'fails to connect' language
jonaswand once you’ve got there, you can properly decouple the two (srv lookup and dial) and provide a third which mixes both
jonasw(i.e. iterates over the records and tries them until either success or fatal error, where not every error is fatal)
moparisthebestin fact SRV couldn't say that, because it supports things other than TCP that don't have a defined 'connection'
SamWhitedI 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.
moparisthebestbut regardless, sounds like we could use some good on-list discussion about proper SRV fallback behavior
jonaswmoparisthebest, that sounds sensible
moparisthebestand then put some if not all of it in xep-368
SamWhitedIf 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
moparisthebestI guess waiting so long before final turns out to be a good idea 🙂
jonaswSamWhited, ah I see
moparisthebestSamWhited, wouldn't a lib like that take a username+password ?
moparisthebestin which case it'd know if it reached auth yet
SamWhitedmoparisthebest: no, it's just dialing TCP connections, it doesn't know anything about XMPP
moparisthebestoh, well, that's odd
jonaswI tend to agree
moparisthebestespecially for direct TLS
SamWhitedIt 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.
jonaswyeah, I don’t think that’s good
SamWhitedWhy not?
Flowdefine "valid connection"
SamWhited"a tcp socket was established"
moparisthebestso it doesn't check TLS cert either?
Flowthere you have your issue
SamWhitedI can't remember, it might do TLS
ralphmhas joined
jonaswSamWhited, the server could be telling you that it is out of capacity currently
moparisthebesta xmpp connection is in my opinion a negotiated stream over a valid TLS connection
moparisthebestso like, after you get that far, maybe don't fallback
moparisthebestbut before you should absolutely fallback
Flowmopharisthebest: 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?
moparisthebestFlow, yea I fired up dino and it failed to connect 😛
Flowahh because of alpn
moparisthebestsame with conversations with my initial patch, but I was already deep in that code so I fixed it
jjrhhas left
SamWhitedI 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.
moparisthebestSamWhited, SRV has nothing to do with TCP and therefore nothing to do with connections
moparisthebestif you want to go up that high
moparisthebestimagine a _udp SRV record, what a successfull connection entails is entirely application layer
moparisthebestsame here imho
Flowyep, it feels like SRV records to be more at the application layer
SamWhitedYah, I actually have some separation there too but it's not relavant for this discussion
SamWhitedBut the retrying is just about dialing TCP sockets, it's definitely not application layer
jonaswSamWhited, it could also simply timeout after accepting the TCP connection
moparisthebeststill disagree
jonaswbecause the server is massively overloaded
SamWhitedOr rather, not application protocol layer. It has nothing to do with XMPP and I don't want it to know about XMPP.
jonaswand you should be trying the next one
jonaswyou can’t tell that purely from the TCP layer
moparisthebestthen how do _udp SRV records work?
jonaswSamWhited, make XMPP know about the SRV records, not the SRV records know about XMPP.
SamWhitedThese aren't udp SRV records, but fair enough, I don't know
la|r|mahas left
SamWhitedjonasw: 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
jonaswSamWhited, not necessarily
moparisthebestbasically 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
moparisthebestI don't think either stance is necessarily wrong or right, just needs to be agreed upon and written down and followed 🙂
jonaswas 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.
moparisthebestbut 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
SamWhitedAt 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?
moparisthebestwell then your library doesn't work with my server
moparisthebestwhich I guess is fine, unless my server happens to be huge like conversations.im or something
jonaswSamWhited, it is a compatibility issue with XEP-0368 servers which require ALPN.
Flowthe xep should at least recommend fallback on invalid cert/xml
moparisthebestI have to patch 368 support out of dino to use it currently, for example
jonaswmoparisthebest, would you care to fire an aioxmpp exmaple against your server?
moparisthebestas added fun, my server does not require alpn over ipv6 😛 (which, having unlimited addresses, I multiplex that way instead of sslh...)
SamWhitedWhy 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?
moparisthebestjonasw, I can make you a test account if you like
jonaswmoparisthebest, EBUSY currently
jonaswand I’ll likely forget about it :/
moparisthebestSamWhited, 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)."
jonaswSamWhited, xmpps-server requiring ALPN over v4, but not over v6 and in addition a fall-abck xmpp-server RR seems like a reasonable setup
moparisthebestwhich obviously expects clients to fallback when hit with invalid xml or whatever
jonaswmoparisthebest, I don’t find that obvious tbh :)
jonaswbut that may simply be my lack of domain knowledge
moparisthebestjonasw, well obvious to me, but in hindsight, I fully agree with you 😛
moparisthebestagain, no one ever accused me of being an english wizard 😛
SamWhitedAh, 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
moparisthebestwell, or falling back at all
moparisthebestI think my current SRV setup is 443 first (which requires alpn or you get invalid xml) and then 5223 next
moparisthebestand then 5222/starttls
moparisthebestif we decide fallback stops at tcp connect I'd need to move priority to 5223 first, 5222 second, 443 last
SamWhitedTangentially 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?
moparisthebestyou could, only http2 browsers will do it though
SamWhitedahh, right
moparisthebestwhich is most newish/secure ones for sure
SamWhitedWill they do it for http/1.1 as well though, or just http/2?
moparisthebestI think they do it for both
moparisthebestI know http/1.1 is defined, not sure if I've ever actually checked honestly
moparisthebestalso this would need updated https://wiki.xmpp.org/web/Tech_pages/XEP-0368
moparisthebestin hindsight I fully assumed fallback would happen regardless 🙂
jjrhhas left
jjrhhas left
jjrhhas left
Alexhas left
Tobiashas left
Alexhas joined
jjrhhas left
uchas joined
valohas left
valohas joined
danielhas left
danielhas joined
jjrhhas left
danielhas left
jjrhhas left
danielhas joined
jonaswhas left
danielhas left
danielhas joined
Dave Cridlandhas left
Guushas left
jjrhhas left
jjrhhas left
lskdjfhas left
ralphmhas joined
had-hochas left
ralphmhas left
goffihas left
Guushas left
jerehas joined
danielhas left
danielhas joined
had-hochas joined
jerehas joined
danielhas left
danielhas joined
Flowhas joined
zinidmoparisthebest, "prosody legacy port"
moparisthebestzinid, yea prosody devs need to alias that to 'direct_tls_port' 😛
zinidmoparisthebest, I think the article shouldn't assume the server name
moparisthebestzinid, what does ejabberd call it? I assume something similar
zinidjust replace prosody with 'xmpp server'
zinidthe text is valid for all servers
moparisthebestwell I wanted to be explicit, I'll put 'prosody legacy_ssl_port' or ejabberd whatever_that_calls_it
zinidnginx
zinidwhat if I use haproxy?
ralphmhas joined
moparisthebestit's not a spec it's an example
zinidok, so I will copy it, replace names and submit to the wiki?
zinidbecause I cannot refer to the article in this version
moparisthebestsure if it's useful 😛
moparisthebestit's more meant for people who followed a tutorial to set up prosody or something
moparisthebestpeople who can read specs probably don't need it
zinidas I said above, sslh config is the same for *any* xmpp/imap/http server
moparisthebestyes, but if I say like 'xmpp server direct tls port' then you have to search docs to discover what that's named
moparisthebestso I'd like to say xmpp server direct tls port (prosody legacy_ssl_ports, ejabberd whatever_its_called)
zinidwhat?
moparisthebestand then https port (nginx, apache)
moparisthebestor whatever, in the comments
moparisthebestI thought it was pretty obvious you didn't *have* to use prosody
moparisthebestbut feel free to update the wiki with ejabberd name or whatever too, it's a wiki
zinidnah, it is better to rename the page to prosody-nginx-openssh-dovecot related configuration
zinidthen I'm fine with it
moparisthebesthaha
zinidanyway, I don't remember my account credentials, so
moparisthebestif 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
zinidmoparisthebest, nice logic
zinidmoparisthebest, why didn't you put 'prosody' everywhere in xep-0368 instead of 'xmpp server'?
zinidif someone can't figure that, oh well...
moparisthebestbecause it's a spec, not a friendly hand-holdy example 😛
zinidbut your logic still applies
moparisthebestit's like a tutorial or an example, that's all
moparisthebestmake it too generic and it gets useless, like I said, I'm fine with adding what ejabberd calls it in there
zinidejabberd doesn't call anything related to this