XSF Discussion - 2018-01-08

Afternoon, all.

Greetings!

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

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

link ?

two(!) protoxeps

you want me to fail my exams!!!k

I may take care of them tonight

jonasw, No problem.

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

I understood, and also I was joking :)

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.

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

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.

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

okay good

will have a look at it asap

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

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

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

Ge0rG, That would, of course, be nuts.

Dave Cridland: and with client key?

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

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

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

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

Neither.

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

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

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

jonasw: I LOLed.

sleekxmpp actually does that.

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

Seems orthogonal to this.

jonasw, Incorrectly, I'd suggest. The certificate defines how long the identity assertion is warranted for, not how long the identity might last.

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

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

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

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.

ah okay, but you could also assume that the identity was then correctly asserted when you connected and don’t need to care anymore.

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

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

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

oopps

and thanks

build in progress, ETA ≤ 2h

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

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

not security, rather improved security leading to account locking

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

yes

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

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.

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

jonasw: yes

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

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

Hi Flow! Were just talking about you ;)

what a coincidence :)

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

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

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

TLS session reuse also comes to mind in this context.

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

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.

Do you stop being you when your cert expires?

yes

Zash: you can't know for sure.

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.

Why must everything be a SASL mechanism?

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

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

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

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

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.

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.

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

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

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

Ge0rG, Yeah, probably.

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.

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

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.

This is pretty similar to account recovery, though.

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

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

Ge0rG, checking :)

marc: this answer is insufficient.

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

for account creation the account name is reserved

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

Ge0rG, no, because the invitation may expire

account creation

Ah, right.

Puh, I expected a big discussion :D

I should write this down right now...

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

marc: yes

okay, good

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

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

marc, the former

a PR to the xeps repo

For those that are interested: I've send out the summit / fosdem hotel group discount details and registration form to the summit mailing list.

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

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.

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

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

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

jonasw, I try to push it to my webserver tomorrow

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

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

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

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

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

marc, don’t worry about that

Ge0rG, will give you a Git tomorrow I think

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

marc: 👍🏽

jonasw, +1 to that.

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

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

zinid: probably a journalistics genius.

Man, that's one seriously transparent Ponzi scheme. ✏

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

of course BFT is slower, especially the one with timeouts

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

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

XeptoCoin?

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

there is already a shitcoin

Oh, right. That trademark thing.

zinid: so we make a JIDcoin

zinid, a ? like only 1 ?

moparisthebest, The XSF can license us, though.

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

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

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

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

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

Ge0rG, Yes, you're right.

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

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

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

what manifesto?

Starting from the bottom usually

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

Ge0rG, With your natural charisma?

not sure what is the goal of the manifesto

to reach a consensus?

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

To reach a long list of good spam-free servers

zinid: get major server admins to agree?

ok, and what practical implications?

Ge0rG, where did you even advertise that?

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

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

jonasw agreed to operate an rbl right? :)

MattJ, nice 🙂

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

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

moparisthebest, I did

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

:>

block ru TLD, be done with spam ;-)

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

I wasn’t serious anyways

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

moparisthebest, yeah, dns it’ll be

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

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

Ge0rG, that’s my ISPs job :>

in a dedicated data center.

on a dedicated Internet.

they have DDoS-protection

at least they advertise it

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

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

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

cloudflare has an API at least

I don’t like cloudflare

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

jonasw, another, yep what Ge0rG said

Ge0rG, that sounds like a good plan.

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

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

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

zinid: yes I do

moparisthebest: do you have stats from them?

Ge0rG, I’ll be happy to :)

Ge0rG, what kind of stats?

but no guarantees :)

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

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

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

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

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)

moparisthebest: great!

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

the likliehood all 3 are ever down seems slim

anyways, gotta go

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

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

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

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

yea, what happened with that?

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

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

And that was when DLV was still a thing

I thought someone from here contacted them

moparisthebest: I did

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

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.

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

I've lost my hope in DNSSEC

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

at least all the new ones are required to have it

Sigh. Clients that ignore the bookmarked nickname for 300.

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

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.

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

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

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

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

Right, I was just typing that :)

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

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

Kev: various things are good, right?

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

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

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.

Multi-device sync.

Of which message routing is a subset, I think.

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

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

No, definitely the other way around :)

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

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

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

It also *might* include highlighting notifications potentially.

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

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

There is *huge* overlap with push.

Except when E2EE is involved.

Push is essentially just one instance of highlight/notifications.

Well, you might be right on that one.

Can xmpp 2 ditch STARTLS also?

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

Kev: except in the current ISR spec

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

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

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

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

Or if the goal is to reduce legacy at all

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

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

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

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

Seems like a small beneficial change to me

And so I hear gajim 1.0 beta zinid

all the more so

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

ah I thought this was the push to new RFC

the new routing rules don't conflict?

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

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.

And yes, chunks of 6121 needs overriding.

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

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

wow then they need to stop being an admin

retire, start another career they can do

that's rude

Potato farming is a thing

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

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

moparisthebest, I don't say "full"

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

so your solution is to replace admins?

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

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

moparisthebest, the problem is that XSF cannot replace admins

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

impossible?

how that? I run it without https

it's *getting* impossible

but not impossible so far

you are missing out on all the new features, and are guaranteed to never get new features (new compression, like brotli, http2, etc etc)

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

yeah, the dream of cryptobitches

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

Zash, only a restricted list of authorities 😉

you can self-sign just like always

Ha, good luck with that

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

moparisthebest, but self-sign doesn't work already

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

Dialback is pretty terrible tho

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

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

not for you poor .im victims

but for normal people 🙂

Browsers hate DANE, so good luck with that

I meant for xmpp

as a dialback alternative

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

moparisthebest: but they haven't fixed SRVid certs

that's only an xmpp problem though right?

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

what else uses SRV and enforces valid TLS certs?

moparisthebest, I think mumble can do both

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

Ge0rG, openssl s_client ?

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

but I think most don't enforce valid TLS

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

I think prosody will ignore the alpn part.

sslh in front of it might not though

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

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

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

Let's see how it works out.

does yaxim (the client) support that now?

moparisthebest: no :(

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 🙂

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

define broken

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

or invalid XML would abort the attempts

things like that

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

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

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 🙂

moparisthebest: mod_net_multiplex on :443

I don't get anything from your server though

moparisthebest: give it a valid XML stream

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

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

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

Flow, I think so, why not?

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

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

well only by priority

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

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

what about invalid xml ?

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

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

I never saw such rules ;)

well those I saw

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

I would class any errors as a failure and fallback

including invalid XML or invalid TLS cert=

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

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.

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

why not jonasw ?

I’m just not sure :)

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

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

jonasw, "SRV records yields invalid XML"?

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

moparisthebest, why?

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

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

moparisthebest, you should have written that in the XEP

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?

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

right, I think it's in there

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

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

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

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

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

and probably no fallback

jonasw: what does what?

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

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

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

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

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

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

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

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

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

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

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)

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

I had to roll that myself, too

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

that

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

or at least, invalid TLS or invalid XML

yes.

like where a connection is not established

authentication failure is probably a bad idea to fall back on

or lack of a (client-)required stream feature

yes was going to say not that

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

well, auth

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.

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

maybe the next server has what you are looking for?

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

jonasw, it does the right thing™

moparisthebest, because the servers are supposed to be identical

jonasw, why? where does it say that?

Or, at best, just make development *much* harder since you won't be able to separate your XMPP stuff from your SRV/DNS stuff.

(so sorting and taking weight into consideration)

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

jonasw, yep

Flow, okay

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

(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)

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

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

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

if you get to authentication, quit, otherwise fallback

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

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

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

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.

uhh, a heterogeneous xmpp server cluster, want!

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?

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)

that's at least how conversations works

the SRV code is over at that point

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)

then you should rework that 😛

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.

SamWhited, I think your dial does too much

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

users may have legitimate reasons to override the SRV lookup

(e.g. during testing)

not even rfc6120

so having those two functions separate is definitely required

it uses a vague 'fails to connect' language

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

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

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

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.

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

moparisthebest, that sounds sensible

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

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

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

SamWhited, ah I see

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

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

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

oh, well, that's odd

I tend to agree

especially for direct TLS

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.

yeah, I don’t think that’s good

Why not?

define "valid connection"

"a tcp socket was established"

so it doesn't check TLS cert either?

there you have your issue

I can't remember, it might do TLS

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

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

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

but before you should absolutely fallback

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?

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

ahh because of alpn

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

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.

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

if you want to go up that high

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

same here imho

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

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

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

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

still disagree

because the server is massively overloaded

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

and you should be trying the next one

you can’t tell that purely from the TCP layer

then how do _udp SRV records work?

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

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

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

SamWhited, not necessarily

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

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

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.

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

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?

well then your library doesn't work with my server

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

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

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

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

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

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

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?

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

moparisthebest, EBUSY currently

and I’ll likely forget about it :/

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

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

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

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

but that may simply be my lack of domain knowledge

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

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

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

well, or falling back at all

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

and then 5222/starttls

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

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?

you could, only http2 browsers will do it though

ahh, right

which is most newish/secure ones for sure

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

I think they do it for both

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

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

in hindsight I fully assumed fallback would happen regardless 🙂

moparisthebest, "prosody legacy port"

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

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

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

just replace prosody with 'xmpp server'

the text is valid for all servers

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

nginx

what if I use haproxy?

it's not a spec it's an example

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

because I cannot refer to the article in this version

sure if it's useful 😛

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

people who can read specs probably don't need it

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

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

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

what?

and then https port (nginx, apache)

or whatever, in the comments

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

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

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

then I'm fine with it

haha

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

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

moparisthebest, nice logic

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

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

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

but your logic still applies

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

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

ejabberd doesn't call anything related to this

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

not sure what should be called here and why

and that implied direct tls ?

*implies

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

do you have to specify one or the other?

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

but you cannot specify both

if you don't does it imply starttls ?

no, it implies no starttls

plain connection

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

yes, much better, thanks

np, thanks for ejabberd config info!

does dino support ALPN?

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

moparisthebest: I see