Just submitted one Internet Draft, plus two ProtoXEPs, covering adding TOTP-based 2FA to XMPP.
Dave Cridland
edhelas, You might be interested in that, as I recall.
edhelas
link ?
jonasw
two(!) protoxeps
jonasw
you want me to fail my exams!!!k
jonasw
I may take care of them tonight
Dave Cridland
jonasw, No problem.
Dave Cridland
jonasw, As in, no rush - not that your exams aren't a problem.
jonasw
I understood, and also I was joking :)
suzyohas joined
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.
jjrhhas left
Dave Cridland
edhelas, The Internet Draft is here: https://datatracker.ietf.org/doc/draft-cridland-kitten-clientkey/
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.
Dave Cridland
edhelas, It demands a few supporting functions from the containing protocol, which is the other ProtoXEP.
edhelas
okay good
edhelas
will have a look at it asap
Ge0rG
Dave Cridland: how often is it supposed to ask for TOTP veriifcation?
Dave Cridland
Ge0rG, Without the CLIENT-KEY mechanism? Every time.
Ge0rG
Dave Cridland: this question is generally interesting to me in the context of long-living TCP sessions, but also for 0198 and ISR
Dave Cridland
Ge0rG, That would, of course, be nuts.
Ge0rG
Dave Cridland: and with client key?
Dave Cridland
Ge0rG, With CLIENT-KEY, it wouldn't. But CLIENT-KEY has expiry and things built in, to force users to reauthenticate.
jjrhhas left
jonasw
Dave Cridland, Builds/xeps/inbox/totp-2fa.xml: not well-formed (invalid token): line 99, column 61
danielhas left
danielhas joined
Dave Cridland
jonasw, Yeah, the ABNF. On it...
Ge0rG
Dave Cridland: will CLIENT-KEY expiry close the session, or require an in-session reauth?
Dave Cridland
Neither.
jerehas joined
Ge0rG
So if I have a good network, I can stay logged in forever?
jonasw
at some point, the servers certificate will expire and your client will of course disconnect you :)
Dave Cridland
Ge0rG, Sure. I imagine if a server admin thought this was a problem they could put in a session expiry.
Ge0rG
jonasw: I LOLed.
jonasw
sleekxmpp actually does that.
Kev
Presumably if there is an issue with authentication of long-lived sessions, this goes beyond the tokens, and would apply to all sessions.
Kev
Seems orthogonal to this.
ralphmhas joined
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.
jjrhhas left
Dave Cridland
jonasw, Travis is back doing its magic on an update.
jonasw
Dave Cridland, not sure. If I actually managed to steal a certificate, long-running sessions would fall for me longer than needed.
Dave Cridland
jonasw, Quite possibly. But that's not what the certificate expiry is for.
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.
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.
jonasw
Dave Cridland, built for website in progress, ETA 2h
jjrhhas left
mathieuii
Dave 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
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 :)
Steve Kille
oopps
Steve Kille
and thanks
jonasw
build in progress, ETA β€ 2h
mathieuii
one of my concerns is that most services offering TOTP have "recovery codes" the user can use when they lose their secret
jjrhhas left
Ge0rG
mathieuii: is that a sentiment about lack of security of 2FA implementations?
mathieuii
not security, rather improved security leading to account locking
Ge0rG
it should be really hard but not impossible to recover from a 2FA loss
mathieuii
yes
mathieuii
well, currently thereβs no standard for password recovery either, so thatβs consistent at least
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.
jonasw
isnβt that the whole idea of ISR+0198?
Ge0rG
jonasw: yes
Ge0rG
jonasw: but consider a pre-ISR pre-CLIENT-KEY world, where the user enters a TOTP token value on each login.
Ge0rG
how long should that authenticated session be considered valid? Until the expiry of the server SSL cert?
Flowhas joined
Ge0rG
Hi Flow! Were just talking about you ;)
Flow
what a coincidence :)
MattJ
It's similar to the question of whether s2s connections should close when the cert that was used to authenticate them expires
Ge0rG
I tend to agree with Kev that it's somewhat orthogonal to SSL cert lifetime, though.
Ge0rG
The question still remains, how long and under which conditions a session should be considered valid.
Ge0rG
TLS session reuse also comes to mind in this context.
Ge0rG
But I'm not very inclined to outsource the reauth of a layer 7 client session to TLS.
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.
Zash
Do you stop being you when your cert expires?
mathieuii
yes
Ge0rG
Zash: you can't know for sure.
ralphmhas joined
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.
Ge0rG
Why must everything be a SASL mechanism?
Dave Cridland
Ge0rG, Because it's an authentication, and that's where authentications live in XMPP.
Ge0rG
So it requires to re-login to enter the unlock code?
Dave Cridland
Ge0rG, No, an unlock code *is* an authentication.
Dave Cridlandhas left
Dave Cridlandhas left
Ge0rG
Dave Cridland: oh, maybe I have a different understanding of that term then.
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.
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.
Ge0rG
Dave Cridland: what you are describing sounds like a password|credentials reset mechanism, which of course _is_ an authentication
Dave Cridland
Ge0rG, Ah, I see. No, I was meaning the codes to unlock/recover an account when the TOTP is lost.
Ge0rG
so maybe "account recovery" would be a better term, then
Dave Cridland
Ge0rG, Yeah, probably.
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.
Ge0rG
Though I must admit I don't particularly like that approach.
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.
Ge0rG
This is pretty similar to account recovery, though.
marc
Ge0rG, didn't follow the discussion but the account doesn't exists in my approach
Ge0rG
marc: how do you ensure that nobody else registers the same account?
marc
Ge0rG, checking :)
Ge0rG
marc: this answer is insufficient.
marc
Ge0rG, for user invitation you don't have the problem
marc
for account creation the account name is reserved
Holgerhas left
Ge0rG
marc: the easiest way to reserve an account name is to regiser that account, isn't it?
marc
Ge0rG, no, because the invitation may expire
marc
account creation
Ge0rG
Ah, right.
marc
Puh, I expected a big discussion :D
marc
I should write this down right now...
marc
Ge0rG, btw, we still need the ibr=true query parameter, right?
Ge0rG
marc: yes
marc
okay, good
jonasw
marc, howβs your progress on submitting the protoxep?
marc
jonasw, what does submitting mean? Official submitting or publishing it on my web server?
jonasw
marc, the former
jonasw
a PR to the xeps repo
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.
vanitasvitaehas left
marc
I don't know how a protoXEP should look like before submitting it
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.
vanitasvitaehas joined
vanitasvitaehas left
Ge0rG
The 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
marc
jonasw, I need a better motivation and probably some other stuff is missing
marc
jonasw, I try to push it to my webserver tomorrow
marc
So you guys can look at it, give some feedback before pushing it to xsf repo
Ge0rG
marc: I can help you writing some sections. Just give me a git π
jonasw
I feel that this feedback should happen in official protoxep or even experimental state.
Ge0rG
I've submitted the astonishing number of 1 xeps already.
marc
jonasw, I don't think so because I expect that there will be some really basic mistakes etc.
jonasw
marc, donβt worry about that
marc
Ge0rG, will give you a Git tomorrow I think
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
Ge0rG
marc: ππ½
hanneshas joined
ralphmhas joined
Dave Cridlandhas left
Dave Cridlandhas left
danielhas left
danielhas joined
Dave Cridland
jonasw, +1 to that.
Dave Cridland
Or more generally, if it's worth working on, it's worth submitting.
zinid
Ge0rG,
> Durov and his brother Nikolai Durov, a mathematical genius
I lol'd. Who wrote this?
Ge0rG
zinid: probably a journalistics genius.
ralphmhas joined
Dave Cridland
Man, that's one seriously transparent Poniz scheme.✎
Dave Cridland
Man, 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.
zinid
of course BFT is slower, especially the one with timeouts
Ge0rG
Now stop bashing the Durovs and let's focus on our own ICO! JabberCoin!
danielhas left
danielhas joined
Ge0rG
I even have a motto for it already: "The brightest light [or lamp?] in crypto moneys!"
intosi
XeptoCoin?
moparisthebest
introducing, JabberCoin! (5 minutes later, sued to death by cisco...)
zinid
there is already a shitcoin
Ge0rG
Oh, right. That trademark thing.
Ge0rG
zinid: so we make a JIDcoin
moparisthebest
zinid, a ? like only 1 ?
Dave Cridland
moparisthebest, The XSF can license us, though.
Ge0rG
Dave Cridland: I'm not sure we can have something that starts with "jabber" and is a commercial entity from the XSF.
zinid: to make a public statement about blocking and shaming abandoned servers.
MattJ
To reach a long list of good spam-free servers
moparisthebest
zinid: get major server admins to agree?
zinid
ok, and what practical implications?
jonasw
Ge0rG, where did you even advertise that?
Ge0rG
jonasw: the manifesto? I asked some server admins so far
MattJ
zinid, if you're not on the list, people may limit/filter/block traffic from your server
moparisthebest
jonasw agreed to operate an rbl right? :)
zinid
MattJ, nice π
zinid
but what if I don't run a public server? I'll be blocked too?
MattJ
If you don't originate spam, I doubt it :)
jonasw
moparisthebest, I did
Ge0rG
XMPP spam is Russian. zinid is Russian. Might get blocked by accident.
jonasw
:>
jonasw
block ru TLD, be done with spam ;-)
Ge0rG
jonasw: no, they are using IBR servers all over the world. Need to block cyrillic letters instead.
jonasw
I wasnβt serious anyways
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 ...
jonasw
moparisthebest, yeah, dns itβll be
jonasw
Iβll also run this on a dedicated machine. I expect some trouble out of it.
Ge0rG
jonasw: you should run it on a dedicated uplink then.
jonasw
Ge0rG, thatβs my ISPs job :>
Ge0rG
in a dedicated data center.
Ge0rG
on a dedicated Internet.
jonasw
they have DDoS-protection
jonasw
at least they advertise it
moparisthebest
you could just let a big DNS provider take care of it for you
jonasw
moparisthebest, thought of that, but I wonder how well updates would work with that
moparisthebest
cloudflare, hurricane electric, I'm sure there are other free ones
moparisthebest
cloudflare has an API at least
jonasw
I donβt like cloudflare
Ge0rG
you could run a hidden primary and have some provider run the secondaries.
moparisthebest
jonasw, another, yep what Ge0rG said
jonasw
Ge0rG, that sounds like a good plan.
danielhas left
danielhas joined
zinid
Ge0rG, do you have s2s dialback enabled on yax.im?
jerehas joined
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
moparisthebest
only ones I could find that support everything I needed, dnssec and such too
Ge0rG
zinid: yes I do
danielhas left
danielhas joined
Ge0rG
moparisthebest: do you have stats from them?
Ge0rGis looking for a new secondary for some zones
jonasw
Ge0rG, Iβll be happy to :)
moparisthebest
Ge0rG, what kind of stats?
jonasw
but no guarantees :)
danielhas left
danielhas joined
Ge0rG
moparisthebest: reliability, speed of zone propagation, such things.
Ge0rGhas been using the freendns dyndns service for some 15 years now
moparisthebest
Ge0rG, so 2 of the 3 providers support the push thing so zone propagation is instant
jonasw
unfortunately, cloudflare thinks that DNS secondary is an enterprise solution :/
moparisthebest
I want to say puck.nether.net is the one that takes up to like 10 minutes
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)
Ge0rG
moparisthebest: great!
moparisthebest
which, is good enough for me, that's why I have 3 different providers and 4 servers π
moparisthebest
the likliehood all 3 are ever down seems slim
jonasw
anyways, gotta go
danielhas left
danielhas joined
danielhas left
danielhas joined
danielhas left
danielhas joined
Ge0rG
Monal. 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
moparisthebest
Ge0rG, this is a good one too (multicast) but no dnssec π’ https://system-ns.com/services/secondary
danielhas left
danielhas joined
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
Ge0rG
moparisthebest: not that I would care about DNSSEC, with the sad .IM situation
moparisthebest
yea, what happened with that?
moparisthebest
last I heard they said they would add support, which had to have been years ago
Ge0rG
moparisthebest: really? Last thing I heard was "not on the agenda"
Dave Cridlandhas left
Dave Cridlandhas left
Ge0rG
And that was when DLV was still a thing
Alexhas joined
moparisthebest
I thought someone from here contacted them
Ge0rG
moparisthebest: I did
Ge0rG
moparisthebest: last time in 2015, "Unfortunately as per our previous correspondence there is still no movement regarding your query."
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.
moparisthebest
wonder if that email still exists, also, you should bug them again Ge0rG π
Ge0rG
I've lost my hope in DNSSEC
moparisthebest
nowadays I don't buy domains unless they have full dnssec support π’
moparisthebest
at 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
Ge0rG
Sigh. Clients that ignore the bookmarked nickname for 300.
Ge0rG
And 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
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.
jerehas joined
ralphmhas joined
Ge0rG
Kev: I think the most probable outcome is me tele-participating.
Ge0rG
Even though I always only get 30% through WebEx :(
Ge0rG
Kev: have you written down any proto-XEP yet?
Kev
I was hoping to get the Informational thing submitted before the summit, but that's looking very tight now. We'll see.
Kev
Right, I was just typing that :)
Ge0rG
Kev: Also, I think last time we limited the scope from XMPP2 down to message routing 2
Kev
I think we need to cover more than just message routing 2, to be able to advance various things.
danielhas left
danielhas joined
Ge0rG
Kev: various things are good, right?
Kev
I don't know which of the possible meanings of that you intend.
Ge0rG
Kev: I hope I can take the time to actually do my presentation; maybe that would be a good prequel to your XMPP2?
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.
Kev
Multi-device sync.
Kev
Of which message routing is a subset, I think.
Kev
I think bind2/sasl2 are part of this too, although maybe they don't currently need discussion.
Ge0rG
Kev: I'd consider multi-device sync as part of the message routing problem.
Kev
No, definitely the other way around :)
Kev
Because sync involves both history fetching and read-state synchronising, neither of which is routing :)
Ge0rG
it's routing to the archive and from the archive ;)
Ge0rG
but it's all part of the same problem, and "multi-device sync" is as good a name as anything.
Kev
It also *might* include highlighting notifications potentially.
Kev
Although that is strictly distinct and can be worked on separately.
Ge0rG
Kev: there is some overlap. And some other overlap with push.
Kev
There is *huge* overlap with push.
Ge0rG
Except when E2EE is involved.
Kev
Push is essentially just one instance of highlight/notifications.
Ge0rG
Well, you might be right on that one.
moparisthebest
Can xmpp 2 ditch STARTLS also?
Kev
I think that's roughly orthogonal, isn't it?
Ge0rG
Kev: except in the current ISR spec
Ge0rG
where there is a `location` pointer to a direct-TLS server.
moparisthebest
Kev: well if the goal is to make things quicker no
Kev
moparisthebest: That isn't the goal of this in general, no.
moparisthebest
One srv query is better than two, plus TLS goodies like 0rtt , fast start etc etc
moparisthebest
Or if the goal is to reduce legacy at all
Kev
Yes, not arguing that going back to 'xmpps' isn't sensible, but I don't see that as part of the same problem.
Kev
No, reducing legacy isn't an aim in itself.
moparisthebest
Well like Ge0rG said isr requires direct TLS, if you don't drop STARTLS all new servers need to support both
zinid
everyone went back to xmpps already, after configuring direct-tls on my server, all my clients automatically switched on it (dino and conversations)
moparisthebest
Seems like a small beneficial change to me
bearhas left
moparisthebest
And so I hear gajim 1.0 beta zinid
zinid
all the more so
Guushas left
Kev
moparisthebest: We can't drop STARTTLS for as long as we have 6120. Which I've no interest in replacing.
bearhas joined
moparisthebest
ah I thought this was the push to new RFC
moparisthebest
the new routing rules don't conflict?
tuxhas joined
zinid
6120 is okayish, it's 6121 which should be replaced, IMO
zinidhas left
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.
Kev
And yes, chunks of 6121 needs overriding.
jjrhhas left
Guushas left
Dave Cridlandhas left
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
@Alacerhas left
Dave Cridlandhas left
zinid
I think dialback makes sense, not every admin understands PKIX currently
moparisthebest
wow then they need to stop being an admin
moparisthebest
retire, start another career they can do
zinid
that's rude
Ge0rG
Potato farming is a thing
moparisthebest
you don't need to have a full understanding of everything involved in PKIX or anything
zinid
I kinda agree, but don't want to lose customers π
zinid
moparisthebest, I don't say "full"
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
zinid
so your solution is to replace admins?
efrithas left
moparisthebest
I haven't met an admin that couldn't do it
moparisthebest
if such an admin exists and refuses to learn, yes, replace them
zinid
moparisthebest, the problem is that XSF cannot replace admins
ralphmhas left
moparisthebest
it's getting impossible to run http without https, if it's good enough for http, it's surely good enough for xmpp
zinid
impossible?
zinid
how that? I run it without https
moparisthebest
it's *getting* impossible
zinid
but not impossible so far
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)
moparisthebest
*and* soon browsers will issue ugly 'insecure' warnings
zinid
yeah, the dream of cryptobitches
Zash
I hope you enjoy the future where you must get permission from some authority to host a website.
zinid
Zash, only a restricted list of authorities π
@Alacerhas joined
moparisthebest
you can self-sign just like always
Zash
Ha, good luck with that
moparisthebest
just import it into your trusted CA list on every machine π
zinid
moparisthebest, but self-sign doesn't work already
zinid
also, dialback resolves the issue: you can self-sign
Zash
Dialback is pretty terrible tho
moparisthebest
I think dnssec+dane solves the issue without CAs too right?
Ge0rG
I love how browsers have made self-signed SSL appear less secure than plain-text HTTP.
moparisthebest
not for you poor .im victims
moparisthebest
but for normal people π
Zash
Browsers hate DANE, so good luck with that
moparisthebest
I meant for xmpp
moparisthebest
as a dialback alternative
Zashhas left
marchas joined
Steve Killehas left
Steve Killehas left
jjrhhas left
jjrhhas left
Zashhas left
Dave Cridlandhas left
hanneshas joined
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
Steve Killehas joined
Ge0rG
moparisthebest: but they haven't fixed SRVid certs
moparisthebest
that's only an xmpp problem though right?
Ge0rG
moparisthebest: no, it's a non-web problem.
moparisthebest
what else uses SRV and enforces valid TLS certs?
jonasw
moparisthebest, I think mumble can do both
Dave Cridlandhas left
Dave Cridlandhas left
Ge0rG
So how can I test Direct-TLS before activating the SRV records?
moparisthebest
Ge0rG, openssl s_client ?
Ge0rG
SRV is used by LDAP, SIP and... *Minecraft*!
moparisthebest
but I think most don't enforce valid TLS
jjrhhas left
jjrhhas left
moparisthebest
Ge0rG, 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
Ge0rG
I think prosody will ignore the alpn part.
jjrhhas left
uchas joined
jjrhhas left
moparisthebest
sslh in front of it might not though
moparisthebest
-servername and -alpn may not be needed depending on server setup
Ge0rG
But 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.
Ge0rG
Let's see how it works out.
moparisthebest
does yaxim (the client) support that now?
jjrhhas left
georghas joined
Ge0rG
moparisthebest: no :(
georghas left
jjrhhas left
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 π
moparisthebest
I need to setup like bad.example.org for some test cases or something, one day
Syndacehas left
uchas joined
ralphmhas joined
jjrhhas left
jonasw
define broken
Zashhas left
Syndacehas joined
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
moparisthebest
or invalid XML would abort the attempts
moparisthebest
things like that
Ge0rG
So my server is slowly accepting more and more connections on :443.
Syndacehas left
Syndacehas joined
moparisthebest
Ge0rG, how do you have it set up? I can't tell from my end
moparisthebest
usually I'd just 'openssl s_client -connect 212.21.75.16:443 -servername yax.im -alpn xmpp-client', type something, hit enter, and either get junk from nginx or prosody π
Ge0rG
moparisthebest: mod_net_multiplex on :443
moparisthebest
I don't get anything from your server though
Ge0rG
moparisthebest: give it a valid XML stream
Ge0rG
It's been enabled for a year, but I never managed to test and add the SRV record.
Syndacehas left
Syndacehas joined
jjrhhas left
moparisthebest
hmm I can't find any docs on that module, didn't know it existed
Flow
moparisthebest: so an invalid cert should be ignored and the next SRV RR tried?
moparisthebest
Flow, I think so, why not?
jjrhhas left
Flow
moparisthebest, dunno, do browser try a different A/AAAA RR if the cert is invalid?
moparisthebest
probably not, but those aren't SRV records where you *should* try next
Flow
well only by priority
Flow
and it's also debatable if an invalid cert should trigger a fallback
Flow
but if that's what we want, then xep368 should mention it
moparisthebest
what about invalid xml ?
moparisthebest
I actually don't know, it should follow same rules as normal starttls srv fallback I guess
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."
Flow
I never saw such rules ;)
Flow
well those I saw
moparisthebest
I guess the debate is what 'fails to connect' means π
moparisthebest
I would class any errors as a failure and fallback
moparisthebest
including invalid XML or invalid TLS cert=
Flow
anyway, SRV fallback on invalid cert would possibly be a good idea to aid cert migration or so
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.
jonasw
moparisthebest, Iβm not sure that "try another SRV record" is the appropriate course of action if one SRV records yields invalid XML...
moparisthebest
why not jonasw ?
jonasw
Iβm just not sure :)
SamWhited
SRV/TCP connection and the application layer protocol are two different layers of the stack that shouldn't be mixed.
moparisthebest
if so xep-368 is useless and should be abandoned π
Flow
jonasw, "SRV records yields invalid XML"?
jonasw
Flow, s/if one SRV records/if a server on a specific SRV record/
jonasw
moparisthebest, why?
moparisthebest
try any account on burtrum.org over ipv4 on any client that doesn't implement ALPN (dino for instance)
moparisthebest
it fails to connect, because if you don't send alpn, you get a non-xml response from nginx
jonasw
moparisthebest, you should have written that in the XEP
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?
jonasw
clients do not have to set the ALPN. it thus has to work without it.
moparisthebest
right, I think it's in there
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).
moparisthebest
so I have additional SRV records that don't require ALPN, because I expect clients to fall back π
jonasw
I 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.
jonasw
Iβm pretty sure that bad thingsβ’ happen with aioxmpp
jonasw
and probably no fallback
jonasw
SamWhited, it does, thatβs specified in XEP-0368✎
SamWhited
jonasw: what does what?
moparisthebest
SamWhited, that xep suggests mixing them as if they are one set of SRV records
jonasw
SamWhited, it is (part of the normal SRV fallback), thatβs specified in XEP-0368 ✏
Flow
what jonas said, the xep should mention it, especially since we have evindence that most developers forget about the fallback case(s)
SamWhited
Oh geeze, I thought that got taken out. That makes no sense and I will be ignoring it.
moparisthebest
when I wrote it I assumed fallback would just work, I had to make it work in conversations
moparisthebest
but yea I'm just now noticing clients not handling it well
jonasw
SamWhited, itβs "just" a SHOULD, but in fact the first point in the rules :)
moparisthebest
so I agree, that should be in implementation notes now π
Dave Cridlandhas left
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
moparisthebest
yes it used to be MUST but someone ( ralphm I think) pointed out they might want to JUST query xmpps-client
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)
jonasw
are there DNS libraries which handle SRV logic? ;-)
jonasw
I had to roll that myself, too
moparisthebest
most I've seen give you a list, and you have to sort/try them yourself
jonasw
that
moparisthebest
but does anyone see harm in falling back in any type of 'non-success' ?
moparisthebest
or at least, invalid TLS or invalid XML
jonasw
yes.
moparisthebest
like where a connection is not established
jonasw
authentication failure is probably a bad idea to fall back on
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.
moparisthebest
a lack of client-required stream feature, why not fall back?
moparisthebest
maybe the next server has what you are looking for?
jonasw
Flow, I canβt tell from the code whether that does the sorting?
Flow
jonasw, it does the right thingβ’
jonasw
moparisthebest, because the servers are supposed to be identical
moparisthebest
jonasw, why? where does it say that?
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.
Flow
(so sorting and taking weight into consideration)
jonasw
Flow, so it returns an iterable of SRV records which I can try in that order?
Flow
jonasw, yep
jonasw
Flow, okay
jonasw
does 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)
Flow
hmm fallback on invalid XML and cert, yes, but on authentication failure? noβ¦
jjrhhas left
moparisthebest
yea I think maybe that would be a sensible place to draw the line
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
moparisthebest
if you get to authentication, quit, otherwise fallback
Flow
jonasw, I don't think that you are supposed to try multiple RRs from the same priority
moparisthebest
jonasw, why, maybe they run ejabberd on one server and prosody on the other and have some home-grown thing to connect them?
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
valohas joined
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.
Flow
uhh, a heterogeneous xmpp server cluster, want!
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?
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)
moparisthebest
that's at least how conversations works
jonasw
the SRV code is over at that point
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)
moparisthebest
then you should rework that π
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.
jonasw
SamWhited, I think your dial does too much
moparisthebest
I don't see anywhere where SRV says fallback only in the event of TCP not connecting
jonasw
users may have legitimate reasons to override the SRV lookup
jonasw
(e.g. during testing)
moparisthebest
not even rfc6120
jonasw
so having those two functions separate is definitely required
moparisthebest
it uses a vague 'fails to connect' language
jonasw
and 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)
moparisthebest
in fact SRV couldn't say that, because it supports things other than TCP that don't have a defined 'connection'
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.
moparisthebest
but regardless, sounds like we could use some good on-list discussion about proper SRV fallback behavior
jonasw
moparisthebest, that sounds sensible
moparisthebest
and then put some if not all of it in xep-368
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
moparisthebest
I guess waiting so long before final turns out to be a good idea π
jonasw
SamWhited, ah I see
moparisthebest
SamWhited, wouldn't a lib like that take a username+password ?
moparisthebest
in which case it'd know if it reached auth yet
SamWhited
moparisthebest: no, it's just dialing TCP connections, it doesn't know anything about XMPP
moparisthebest
oh, well, that's odd
jonasw
I tend to agree
moparisthebest
especially for direct TLS
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.
jonasw
yeah, I donβt think thatβs good
SamWhited
Why not?
Flow
define "valid connection"
SamWhited
"a tcp socket was established"
moparisthebest
so it doesn't check TLS cert either?
Flow
there you have your issue
SamWhited
I can't remember, it might do TLS
ralphmhas joined
jonasw
SamWhited, the server could be telling you that it is out of capacity currently
moparisthebest
a xmpp connection is in my opinion a negotiated stream over a valid TLS connection
moparisthebest
so like, after you get that far, maybe don't fallback
moparisthebest
but before you should absolutely fallback
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?
moparisthebest
Flow, yea I fired up dino and it failed to connect π
Flow
ahh because of alpn
moparisthebest
same with conversations with my initial patch, but I was already deep in that code so I fixed it
jjrhhas left
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.
moparisthebest
SamWhited, SRV has nothing to do with TCP and therefore nothing to do with connections
moparisthebest
if you want to go up that high
moparisthebest
imagine a _udp SRV record, what a successfull connection entails is entirely application layer
moparisthebest
same here imho
Flow
yep, it feels like SRV records to be more at the application layer
SamWhited
Yah, I actually have some separation there too but it's not relavant for this discussion
SamWhited
But the retrying is just about dialing TCP sockets, it's definitely not application layer
jonasw
SamWhited, it could also simply timeout after accepting the TCP connection
moparisthebest
still disagree
jonasw
because the server is massively overloaded
SamWhited
Or rather, not application protocol layer. It has nothing to do with XMPP and I don't want it to know about XMPP.
jonasw
and you should be trying the next one
jonasw
you canβt tell that purely from the TCP layer
moparisthebest
then how do _udp SRV records work?
jonasw
SamWhited, make XMPP know about the SRV records, not the SRV records know about XMPP.
SamWhited
These aren't udp SRV records, but fair enough, I don't know
la|r|mahas left
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
jonasw
SamWhited, not necessarily
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
moparisthebest
I don't think either stance is necessarily wrong or right, just needs to be agreed upon and written down and followed π
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.
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
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?
moparisthebest
well then your library doesn't work with my server
moparisthebest
which I guess is fine, unless my server happens to be huge like conversations.im or something
jonasw
SamWhited, it is a compatibility issue with XEP-0368 servers which require ALPN.
Flow
the xep should at least recommend fallback on invalid cert/xml
moparisthebest
I have to patch 368 support out of dino to use it currently, for example
jonasw
moparisthebest, would you care to fire an aioxmpp exmaple against your server?
moparisthebest
as added fun, my server does not require alpn over ipv6 π (which, having unlimited addresses, I multiplex that way instead of sslh...)
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?
moparisthebest
jonasw, I can make you a test account if you like
jonasw
moparisthebest, EBUSY currently
jonasw
and Iβll likely forget about it :/
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)."
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
moparisthebest
which obviously expects clients to fallback when hit with invalid xml or whatever
jonasw
moparisthebest, I donβt find that obvious tbh :)
jonasw
but that may simply be my lack of domain knowledge
moparisthebest
jonasw, well obvious to me, but in hindsight, I fully agree with you π
moparisthebest
again, no one ever accused me of being an english wizard π
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
moparisthebest
well, or falling back at all
moparisthebest
I think my current SRV setup is 443 first (which requires alpn or you get invalid xml) and then 5223 next
moparisthebest
and then 5222/starttls
moparisthebest
if we decide fallback stops at tcp connect I'd need to move priority to 5223 first, 5222 second, 443 last
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?
moparisthebest
you could, only http2 browsers will do it though
SamWhited
ahh, right
moparisthebest
which is most newish/secure ones for sure
SamWhited
Will they do it for http/1.1 as well though, or just http/2?
moparisthebest
I think they do it for both
moparisthebest
I know http/1.1 is defined, not sure if I've ever actually checked honestly
moparisthebest
also this would need updated https://wiki.xmpp.org/web/Tech_pages/XEP-0368
moparisthebest
in 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
zinid
moparisthebest, "prosody legacy port"
moparisthebest
zinid, yea prosody devs need to alias that to 'direct_tls_port' π
zinid
moparisthebest, I think the article shouldn't assume the server name
moparisthebest
zinid, what does ejabberd call it? I assume something similar
zinid
just replace prosody with 'xmpp server'
zinid
the text is valid for all servers
moparisthebest
well I wanted to be explicit, I'll put 'prosody legacy_ssl_port' or ejabberd whatever_that_calls_it
zinid
nginx
zinid
what if I use haproxy?
ralphmhas joined
moparisthebest
it's not a spec it's an example
zinid
ok, so I will copy it, replace names and submit to the wiki?
zinid
because I cannot refer to the article in this version
moparisthebest
sure if it's useful π
moparisthebest
it's more meant for people who followed a tutorial to set up prosody or something
moparisthebest
people who can read specs probably don't need it
zinid
as I said above, sslh config is the same for *any* xmpp/imap/http server
moparisthebest
yes, but if I say like 'xmpp server direct tls port' then you have to search docs to discover what that's named
moparisthebest
so I'd like to say xmpp server direct tls port (prosody legacy_ssl_ports, ejabberd whatever_its_called)
zinid
what?
moparisthebest
and then https port (nginx, apache)
moparisthebest
or whatever, in the comments
moparisthebest
I thought it was pretty obvious you didn't *have* to use prosody
moparisthebest
but feel free to update the wiki with ejabberd name or whatever too, it's a wiki
zinid
nah, it is better to rename the page to prosody-nginx-openssh-dovecot related configuration
zinid
then I'm fine with it
moparisthebest
haha
zinid
anyway, I don't remember my account credentials, so
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
zinid
moparisthebest, nice logic
zinid
moparisthebest, why didn't you put 'prosody' everywhere in xep-0368 instead of 'xmpp server'?
zinid
if someone can't figure that, oh well...
moparisthebest
because it's a spec, not a friendly hand-holdy example π
zinid
but your logic still applies
moparisthebest
it's like a tutorial or an example, that's all
moparisthebest
make it too generic and it gets useless, like I said, I'm fine with adding what ejabberd calls it in there