what would be the best approach to implement "carbons", but for the transport contacts? 🤔 (so the message sent directly through the legacy network can show up in the xmpp conversation)
Guushas left
Guushas joined
equilhas left
Neustradamushas left
jjrhhas left
jjrhhas left
alexishas joined
alacerhas left
Neustradamushas joined
alacerhas joined
alexishas left
alexishas joined
Ge0rG
dos: write a new XEP where the transport is allowed to send carbons to a user
alexishas left
Ge0rG
dos: there was a thread at https://mail.jabber.org/pipermail/standards/2018-January/034224.html
alexishas joined
Guushas left
Ge0rG
f'up at https://mail.jabber.org/pipermail/standards/2018-February/034267.html
alexishas left
alexishas joined
jjrhhas left
jjrhhas left
alexishas left
Guushas joined
moparisthebest
I implemented a, uh, client side transport that way
moparisthebest
Kind of, it's a dumb echo component so carbons and mam and such just work for free
jonas’
dos, https://xmpp.org/extensions/xep-0356.html might be interesting in that regard
alacerhas left
alacerhas joined
jjrhhas left
jjrhhas left
Guushas left
Guushas joined
alacerhas left
alacerhas joined
equilhas left
goffi
dos: what kind of transport are you implementing? Will it be publicly available/libre ?
jjrhhas left
alexishas joined
j.rhas joined
Guushas left
Dave Cridlandhas left
alexishas left
alexishas joined
lskdjfhas left
alexishas left
labdsfhas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
jjrhhas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
UsLhas joined
alacerhas left
alexishas joined
jjrhhas left
alexishas left
Guushas joined
Holgerhas left
jjrhhas left
labdsfhas joined
Guushas left
Guushas joined
labdsfhas left
labdsfhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
labdsfhas left
labdsfhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
labdsfhas left
j.rhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
vanitasvitaehas left
jjrhhas left
jjrhhas left
labdsfhas joined
Guushas left
Dave Cridlandhas left
alexishas joined
Guushas joined
alexishas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
jjrhhas left
alexishas joined
peterhas joined
jjrhhas left
jjrhhas left
lskdjfhas left
matlaghas left
moparisthebesthas left
matlaghas joined
lskdjfhas left
lskdjfhas joined
labdsfhas left
tuxhas joined
jjrhhas left
Dave Cridlandhas left
blablahas left
tuxhas joined
blablahas joined
Guushas left
Guushas joined
vanitasvitaehas left
jjrhhas left
Guushas left
lovetoxhas joined
Guushas joined
lorddavidiiihas left
!xsf_martinhas joined
!xsf_martinhas joined
jjrhhas left
jjrhhas left
Zashhas left
waqashas joined
blablahas joined
lorddavidiiihas joined
jjrhhas left
jjrhhas left
waqashas left
tahas joined
Dave Cridlandhas left
Guushas left
Guushas joined
jjrhhas left
lskdjfhas left
jjrhhas left
Guushas left
waqashas joined
blablahas joined
Steve Killehas left
Steve Killehas left
vanitasvitaehas left
jjrhhas left
jjrhhas left
danielhas left
danielhas joined
Steve Killehas joined
danielhas left
danielhas joined
Tobiashas joined
mimi89999has left
Tobiashas joined
jjrhhas left
jjrhhas left
blablahas joined
equilhas left
equilhas joined
ThibGhas left
ThibGhas joined
Alexhas joined
Tobiashas joined
Tobiashas joined
alacerhas joined
Zashhas left
jjrhhas left
muppethhas left
muppethhas joined
labdsfhas joined
j.rhas joined
Guushas joined
Andrew Nenakhovhas left
blablahas joined
jjrhhas left
jjrhhas left
Dave Cridlandhas left
Maranda
hm any client doing scram-sha256?
Andrew Nenakhovhas left
alexishas joined
SamWhited
Maranda: Conversations does, also my dummy test client https://github.com/mellium/communique-tui
Zashhas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
jjrhhas left
Andrew Nenakhovhas joined
jjrhhas left
tahas joined
Maranda
SamWhited, ok giving it a go then, the code *should* already work with it, I just need to change the hash algorithm.✎
Maranda
SamWhited, ok giving it a go then, the code *should* already work with it, I just need to change the hash algorithm function. ✏
Maranda
(and store sha256 keys)
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Maranda
SamWhited, what Conversations does if one mechanism fails?
Maranda
does it try another?
SamWhited
Maranda: sort of; it falls back but it's also more complicated than that. If it manages to connect successfully the first time it "pins" the auth mechanism used and will only use one with that or a higher level of security in the future to prevent downgrade attacks
SamWhited
So if it uses SCRAM-SHA-1 once it will use SCRAM-SHA-256 if support is added, but if that works and it logs in it won't use SCRAM-SHA-1 anymore.
jjrhhas left
jjrhhas left
Zash
Problem: How do you upgrade the hashes?
Maranda
SamWhited, because obviously users will have to change their password to add SHA256 keys
Maranda
Zash, you don't
Maranda
Zash, I just save keys for both hashing algorithm figured it was much easier that way
SamWhited
Zash: do a rolling upgrade when users change passwords?
Maranda
Indeed
SamWhited
I don't know what's conventional for servers
Maranda
SamWhited, but you'll have to save keys for both SHA1 and SHA256
SamWhited
Maranda: if you want to support both, yes. Otherwise you can just advertise whichever you have keys for for that particular user.
Zash
You don't know which user it is until they try to auth
SamWhited
But yah, given that sha-256 isn't wide spread I'd probably keep both
Maranda
SamWhited, huhu I'd not try with the "not supporting both"
Zash
They have to pick a mechanism first
SamWhited
Zash: oh yah, good point, setting "from" isn't required on streams.
SamWhited
Storing both for now is probably easy enough though
Maranda
For now code just checks if there're keys for one algorithm if not it'll throw a temporary-auth-failure error.
Maranda
that's why I asked what Conversations does :P
j.rhas joined
Marandahas left
Marandahas left
Marandahas joined
j.rhas left
j.rhas joined
Dave Cridlandhas left
ThibGhas joined
ThibGhas joined
jjrhhas left
j.rhas left
j.rhas joined
Dave Cridlandhas left
lumihas left
Guushas left
Guushas joined
Guushas left
jjrhhas left
jjrhhas left
Guushas joined
crowbar.envyhas joined
alexishas left
Marandahas left
Marandahas joined
Marandahas left
jjrhhas left
Marandahas joined
jjrhhas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
derdanielhas left
derdanielhas joined
j.rhas left
j.rhas joined
j.rhas left
j.rhas joined
j.rhas left
j.rhas joined
j.rhas left
j.rhas joined
Marandahas left
Marandahas joined
jjrhhas left
Dave Cridlandhas left
Zashhas left
jjrhhas left
Yagizahas left
Marandahas left
Marandahas joined
Marandahas left
j.rhas left
j.rhas joined
Zashhas left
j.rhas left
Zashhas left
Zashhas joined
!xsf_martinhas left
!xsf_martinhas joined
jjrhhas left
jjrhhas left
peterhas left
jjrhhas left
jjrhhas left
j.rhas joined
equilhas left
karphas left
karphas joined
jjrhhas left
Yagizahas left
Dave Cridlandhas left
danielhas left
!xsf_martinhas joined
tuxhas left
Guushas left
Guushas joined
Guushas left
jjrhhas left
jjrhhas left
!xsf_martinhas joined
labdsfhas left
Guushas joined
jjrhhas left
jjrhhas left
labdsfhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas left
Marandahas joined
Maranda
SamWhited, what's that tester code you mentioned again?
To verify bcrypt or scrypt as is, you need the plain text password. SCRAM doesn't require that
moparisthebest
I have to read up on SCRAM
Zash
You do
jjrhhas left
equilhas joined
Zash
It's not comparable with bcrypt. It uses PBKDF2 which does that kind of job, but then there is XOR magic.
jjrhhas left
Zashhas left
SamWhited
moparisthebest: TL;DR when you want to upgrade, for example, a web apps password from bcrypt and salted to something else, say PBKDF2 or argon2, you wait for the user to log in, then you hash the password with bcrypt, compare to make sure it's the right one, then hash it with the new thing and save the new hash. However, with SCRAM you never actually send the password, you send a verifiable proof that you possess the password, but there's no way to upgrade that proof to a proof for a different scheme.
jonas’
SCRAM is a pretty amazing thing
jonas’
SamWhited, unless you force the user to change passwords
jonas’
or downgrade to PLAIN only, which is what I did. (and which Conversations didn’t let me do painlessly)
jonas’
(which is a good thing imo)
SamWhited
Right, we don't currently have a good way to force upgrades.
SamWhited
It could be done because SCRAM performs mutual authentication, so once the server is authenticated to the client it could send a "please send your password in plain and upgrade to SCRAM-SHA-256" message, but we don't have a way to do that currently.
pep.
IBR doesn't even do SCRAM, which is something I wanted to tackle, but I'll pass the baton to whomever says a word about it :P
Guushas left
Marandahas joined
SamWhited
pep. feel free to provide feedback or implementations of https://xmpp.org/extensions/xep-0389.html
pep.
oh
SamWhited
It needs a lot more work, but part of the idea was to let IBR use regular SASL mechanisms
pep.
Thanks, I completely missed it
jonas’
SamWhited, seems like a thing which SASL2 could do
jonas’
(the upgrade thing)
SamWhited
yah, it's probably something we should think about.
Marandahas joined
jjrhhas left
Marandahas left
Marandahas joined
jjrhhas left
crowbar.envyhas left
SamWhited
Although, it could probably be backwards compatible by just defining a message the server can send to the client at any time that tells it "clear any pinned auth mechanisms" then the server could force a reconnect and only offer PLAIN the next time.
pep.
That kind of defeats the point of doing SCRAM no?
SamWhited
pep. no, because it would only happen after you've authed the server
pep.
What do you mean
SamWhited
You know you're talking to the correct server, so starting over and using something it can generate hashes from is fine
pep.
But the point of SCRAM for me is that the server doesn't know about your plaintext password. So if you do PLAIN ~
Guushas joined
dos
jonas’: thanks, haven't though about 356 for that :)
SamWhited
pep. I suppose that's fair
SamWhited
It seems much better to have a way to flexibly and rapidly upgrade auth mechanisms when an attack is discovered than to worry about a server secretly storing your password when it probably got it at some point when you registered anyways
jjrhhas left
SamWhited
It could also just be a "clear your SCRAM-bits cache and don't start from the intermediate step" message too though, I suppose.
Tobiashas left
Tobiashas joined
pep.
You still need to use some protocol to set your password right with SCRAM, does that exist in 389? I haven't read through. TBH I don't mind doing PLAIN with clients that don't support, they should update, that's not my fault. But if possible I want to keep the assumptions the user has with me
dos
goffi: so far I'm just looking at improving spectrum2; my goal is to have proper facebook, hangouts, discord and maybe matrix bridging for use by me and my friends
SamWhited
pep. no, 0398 just provides a way for you to define challenges. It was my intention to define a SASL one.
pep.
ok
iiro.laihohas joined
SamWhited
But it does add the ability for us to do that
SamWhited
Actually, that one should probably just be one of the mandatory ones that's included in 0398 itself. Right now there's just one for submitting a form like in regular IBR
Zashhas left
Neustradamushas left
Neustradamushas joined
iiro.laihohas left
jjrhhas left
Kevhas joined
Marandagrowls
Maranda
https://pastebin.com/s4usVWMZ
jjrhhas left
jjrhhas left
labdsfhas left
moparisthebest
meh pep. I mean you use a different password with each service anyway, why does it matter if your server has it?
moparisthebest
also lets me support same password for xmpp, email, and http auth easily, and with a strong hash on the server
pep.
moparisthebest, you do, yes
pep.
I am sure 90% of a public service like jabberfr.org doesn't
moparisthebest
my question is, is whatever 'part of scram whatever' that your server stores hard to reverse or not?
pep.
I also do fwiw. It's not me I'm worried about
Kevhas left
alacerhas left
alacerhas joined
labdsfhas joined
jjrhhas left
jjrhhas left
SamWhited
You have to trust the server for the most part anyways, that's part of XMPP's security model and you almost certainly had to send the server your password somehow when you first signed up, so it could have saved it then if it really wanted to
SamWhited
So if you're going to worry about other people reusing passwords and the server saving a plain copy of it, you have a lot more work to do.
lorddavidiiihas left
pep.
SamWhited, yeah, which is why I also want SCRAM/IBR
lorddavidiiihas joined
pep.
step by step
SamWhited
Doesn't seem worth bothering with to me; just send the server your password on occasion. It's not significantly worse from a security standpoint, and might even be significantly better since it allows for more agile password hashing schemes in the event that the one you're using is discovered to be flawed.
SamWhited
But I dunno, I'm just thinking out loud. Maybe there's an easy way to make SCRAM upgrade-able too.
jshas joined
pep.
I wouldn't mind a force password reset fwiw
peterhas joined
Kevhas joined
Kevhas left
j.rhas joined
pep.
I guess we do all that to protect against offline attacks. So when for some reason we want to change hashes, we also don't want to keep $old_hash around, otherwise that defeats the point of why we keep hashes in the first place, which makes us lose the ability to authenticate users at all and certainly require another channel :/
Zash
moparisthebest: The stuff that SCRAM lets you store is hard to reverse, yes.
moparisthebest
but compared to bcrypt/scrypt/?
jjrhhas left
jjrhhas left
moparisthebest
like have cryptographers agreed it is *as* hard to reverse as those
Zash
moparisthebest: It uses a password stretching function called Password Based Key Derivation Function no 2
Zash
I'd put it in the same class of things as bcrypt and scrypt
Zash
I wouldn't consider that part all that important, I'm pretty sure you could switch it out for bcrypt/script/whatever and have the overall SCRAM construct still work
Zash
Thing is, those password stretching functions take a password and some salt and give you a key. SCRAM magic consists of adding two-three layers of hashes on that and some XOR in a way that lets you store the password *everywhere*
Zash
Ie Client can store hashed stuff. Server can store hashed stuff.
Zash
Hashed stuff on the wire.
Maranda
SamWhited, I'm not sure what's wrong here... apparently bxor is broken by some additional x byte in the proof.
moparisthebest
it just sounds very complicated, normally you don't want very complicated in your security proofs
Zash
moparisthebest: It's not all that complicated
Maranda
it's 21 iterations instead of 20, the 21th is truncated and breaks XOR
Zash
moparisthebest: Not sure if you need to understand how it works to understand this description: https://prosody.im/pastebin/6f7b2c8b-8952-458b-a1d2-36d29bacd345
jjrhhas left
jjrhhas left
SamWhited
moparisthebest: PBKDF2 is still considered secure, yes. I beleive OWASP recommends it over scrypt and it's usable if you're looking for FIPS compliance
moparisthebest
yea just wasn't sure if PBKDF2 was what was stored or not
SamWhited
Its weakness is that it can be implemented with very little RAM, scrypt does a better job there
intosihas left
intosihas joined
SamWhited
Yah, you can store the salted password after passing it through PBKDF2 or you can take an hmac of the salted password and a server or client KEY and store that (the "scram bits"). This is what I always store (for no particular reason other than it's one less thing to do later)
j.rhas joined
Zash
"StoredKey" is H(HMAC(PBKDF2(password, salt, i), "Client Key"))
Hmm, I haven't looked at my SASL implementation in a while, this reminds me that I also need to add some mechanism for caching keys or resuming a calculation so that the user can build a mechanism for caching keys
SamWhited
That's going to be a pain to come up with a good API for
efrithas joined
jjrhhas left
jjrhhas left
Marandahas left
Marandahas joined
jshas left
Marandahas left
Marandahas joined
goffihas left
jjrhhas left
jjrhhas left
lorddavidiiihas left
Alexhas left
ThibGhas left
ThibGhas joined
tuxhas joined
jjrhhas left
jjrhhas left
pep.
SamWhited, moparisthebest, fwiw I'd prefer to avoid passwords at all and use client certs I generate. That can leak I don't actually care.
Marandahas left
Marandahas joined
labdsfhas left
labdsfhas joined
Marandahas left
Marandahas joined
Dave Cridlandhas left
moparisthebest
how do you sign in with a new client then?
moparisthebest
if you say password I'm going to ask what the point is :)
jjrhhas left
jjrhhas left
SamWhited
I'd like something like that where when you sign in with a new client it shows a pop-up on your old client and if you hit yes, you're signed in.
pep.
yeah, I was going to say something similar
pep.
Not that I have really researched on the subject
SamWhited
It's hard to get a good UX that way (see OMEMO which is a pain in the ass to use), but I do think it can be done with a lot of work.
pep.
Also you still need another channel for recovery
SamWhited
We should probably get a basic password flow working reasonably well first though.
SamWhited
Yah, recovery is more or less the same no matter what you have. If you want to be able to recover, you need some other channel. Email or what have you.
Zash
What if you have some kind of shared secret that you can remember in your brain?
pep.
Somebody said passwords?
SamWhited
(IBR2 also supports recovery specifically, FWIW)
lnjhas left
pep.
This I really like in 389:
A client SHOULD be able to register an account without requiring the user to leave the client.
A client MUST be able to use the same mechanism to register an account and to recover a forgotten password (subject to server policy).
pep.
Is there a ordering of XEPs that is not by number btw?
ThibGhas joined
pep.
By category, by..
pep.
Ah there's the page on xmpp.org to filter a bit
SamWhited
That SHOULD should probably be relaxed actually; that really heavily depends on the type of service and probably shouldn't be 2119 language.
pep.
meh, I think that's the most important part for easy-onboarding
SamWhited
Yah, but only if you're doing a purely-XMPP personal server. Specs shouldn't be tailored to those.
pep.
right
SamWhited
purely-XMPP-public-Jabber-network, that is.
jjrhhas left
jjrhhas left
pep.
But then you have to make everything optional in specifications if you want to support every use case
j.rhas left
j.rhas joined
SamWhited
I don't want to support every use case, I just don't want to put stupid hard limits in that serve no purpose that everyone will just ignore anyways
SamWhited
The recommendation is good, but RFC 2119 language isn't really suitable here
Syndacehas left
Syndacehas joined
SamWhited
In other words: we can have a design considerations section, but it shouldn't be normative.
pep.
I was saying that more as a general rule, as in, "it's indentally what happens the more use-case you want to support"
lskdjfhas left
SamWhited
I agree with that, but that's not what's happening here
pep.
k
SamWhited
Even if the spec were deliberately an XMPP-only/public jabber spec for some reason, design considerations that are only tangentially related to the spec probably shouldn't be normative 2119 language
jjrhhas left
jjrhhas left
SamWhited
(I'm not suggesting that entire line should be removed, in case I'm not being clear: just that it should say "should" instead of "SHOULD")
danielhas left
pep.
I don't think 2119 mandates CAPS does it
SamWhited
pep. it does (or at least, an update does, I forget exactly where it says that)
pep.
"These words are often capitalized"
pep.
So, no
SamWhited
8174
pep.
oh
SamWhited
I'm saying 2119 out of habit
pep.
hah, I see
pep.
Just for this exact use case :P
lnjhas left
SamWhited
But yah, however it's done I just mean that the language in that sentence should not be normative. I assume lowercase does that, but maybe it would just need to be rephrased.
jshas joined
jshas left
jjrhhas left
jjrhhas left
moparisthebesthas left
lskdjfhas joined
lskdjfhas left
ThibGhas left
ThibGhas joined
peter
My preference as a spec author is to use MUST, SHOULD, MAY etc. only in caps, and to use other words (ought, might, can, etc.) if the normative force is not intended.
jjrhhas left
danielhas left
SamWhited
Agreed; that's probably a good thing to do to reduce confusion.
peter
Precisely.
jshas joined
jjrhhas left
lumihas joined
Zashhas left
blablahas left
blablahas joined
peterhas left
Dave Cridlandhas left
alexishas joined
thorstenhas left
danielhas left
danielhas joined
waqashas left
thorstenhas joined
SamWhitedhas left
alexishas left
lovetoxhas left
jshas left
jjrhhas left
jshas joined
Maranda
Signature 32 bytes, Proof 20 bytes
Maranda
>.>
Maranda
SamWhited, that doesn't look right
Maranda
(what Conversations does)
alexishas joined
alexishas left
Guushas left
Guushas joined
Dave Cridlandhas left
alexishas joined
SamWhited
I'm not at my desk right now but I did test it against a server impl, it's quite possible something is still wrong though (I'm assuming that's in the scram-sha256 code somewhere?)