doswhat 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
Ge0rGdos: write a new XEP where the transport is allowed to send carbons to a user
alexishas left
Ge0rGdos: there was a thread at https://mail.jabber.org/pipermail/standards/2018-January/034224.html
alexishas joined
Guushas left
Ge0rGf'up at https://mail.jabber.org/pipermail/standards/2018-February/034267.html
alexishas left
alexishas joined
jjrhhas left
jjrhhas left
alexishas left
Guushas joined
moparisthebestI implemented a, uh, client side transport that way
moparisthebestKind 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
goffidos: 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
Marandahm any client doing scram-sha256?
Andrew Nenakhovhas left
alexishas joined
SamWhitedMaranda: 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
MarandaSamWhited, ok giving it a go then, the code *should* already work with it, I just need to change the hash algorithm.
MarandaSamWhited, 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
MarandaSamWhited, what Conversations does if one mechanism fails?
Marandadoes it try another?
SamWhitedMaranda: 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
SamWhitedSo 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
ZashProblem: How do you upgrade the hashes?
MarandaSamWhited, because obviously users will have to change their password to add SHA256 keys
MarandaZash, you don't
MarandaZash, I just save keys for both hashing algorithm figured it was much easier that way
SamWhitedZash: do a rolling upgrade when users change passwords?
MarandaIndeed
SamWhitedI don't know what's conventional for servers
MarandaSamWhited, but you'll have to save keys for both SHA1 and SHA256
SamWhitedMaranda: if you want to support both, yes. Otherwise you can just advertise whichever you have keys for for that particular user.
ZashYou don't know which user it is until they try to auth
SamWhitedBut yah, given that sha-256 isn't wide spread I'd probably keep both
MarandaSamWhited, huhu I'd not try with the "not supporting both"
ZashThey have to pick a mechanism first
SamWhitedZash: oh yah, good point, setting "from" isn't required on streams.
SamWhitedStoring both for now is probably easy enough though
MarandaFor now code just checks if there're keys for one algorithm if not it'll throw a temporary-auth-failure error.
Marandathat'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
MarandaSamWhited, what's that tester code you mentioned again?
ZashTo verify bcrypt or scrypt as is, you need the plain text password. SCRAM doesn't require that
moparisthebestI have to read up on SCRAM
ZashYou do
jjrhhas left
equilhas joined
ZashIt's not comparable with bcrypt. It uses PBKDF2 which does that kind of job, but then there is XOR magic.
jjrhhas left
Zashhas left
SamWhitedmoparisthebest: 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)
SamWhitedRight, we don't currently have a good way to force upgrades.
SamWhitedIt 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
SamWhitedpep. feel free to provide feedback or implementations of https://xmpp.org/extensions/xep-0389.html
pep.oh
SamWhitedIt 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)
SamWhitedyah, it's probably something we should think about.
Marandahas joined
jjrhhas left
Marandahas left
Marandahas joined
jjrhhas left
crowbar.envyhas left
SamWhitedAlthough, 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?
SamWhitedpep. no, because it would only happen after you've authed the server
pep.What do you mean
SamWhitedYou 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
dosjonas’: thanks, haven't though about 356 for that :)
SamWhitedpep. I suppose that's fair
SamWhitedIt 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
SamWhitedIt 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
dosgoffi: 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
SamWhitedpep. 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
SamWhitedBut it does add the ability for us to do that
SamWhitedActually, 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
Marandahttps://pastebin.com/s4usVWMZ
jjrhhas left
jjrhhas left
labdsfhas left
moparisthebestmeh pep. I mean you use a different password with each service anyway, why does it matter if your server has it?
moparisthebestalso 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
moparisthebestmy 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
SamWhitedYou 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
SamWhitedSo 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
SamWhitedDoesn'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.
SamWhitedBut 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 :/
Zashmoparisthebest: The stuff that SCRAM lets you store is hard to reverse, yes.
moparisthebestbut compared to bcrypt/scrypt/?
jjrhhas left
jjrhhas left
moparisthebestlike have cryptographers agreed it is *as* hard to reverse as those
Zashmoparisthebest: It uses a password stretching function called Password Based Key Derivation Function no 2
ZashI'd put it in the same class of things as bcrypt and scrypt
ZashI 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
ZashThing 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*
ZashIe Client can store hashed stuff. Server can store hashed stuff.
ZashHashed stuff on the wire.
MarandaSamWhited, I'm not sure what's wrong here... apparently bxor is broken by some additional x byte in the proof.
moparisthebestit just sounds very complicated, normally you don't want very complicated in your security proofs
Zashmoparisthebest: It's not all that complicated
Marandait's 21 iterations instead of 20, the 21th is truncated and breaks XOR
Zashmoparisthebest: 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
SamWhitedmoparisthebest: PBKDF2 is still considered secure, yes. I beleive OWASP recommends it over scrypt and it's usable if you're looking for FIPS compliance
moparisthebestyea just wasn't sure if PBKDF2 was what was stored or not
SamWhitedIts weakness is that it can be implemented with very little RAM, scrypt does a better job there
intosihas left
intosihas joined
SamWhitedYah, 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"))
SamWhitedHmm, 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
SamWhitedThat'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
moparisthebesthow do you sign in with a new client then?
moparisthebestif you say password I'm going to ask what the point is :)
jjrhhas left
jjrhhas left
SamWhitedI'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
SamWhitedIt'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
SamWhitedWe should probably get a basic password flow working reasonably well first though.
SamWhitedYah, 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.
ZashWhat 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
SamWhitedThat 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
SamWhitedYah, but only if you're doing a purely-XMPP personal server. Specs shouldn't be tailored to those.
pep.right
SamWhitedpurely-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
SamWhitedI 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
SamWhitedThe recommendation is good, but RFC 2119 language isn't really suitable here
Syndacehas left
Syndacehas joined
SamWhitedIn 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
SamWhitedI agree with that, but that's not what's happening here
pep.k
SamWhitedEven 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
SamWhitedpep. it does (or at least, an update does, I forget exactly where it says that)
pep."These words are often capitalized"
pep.So, no
SamWhited8174
pep.oh
SamWhitedI'm saying 2119 out of habit
pep.hah, I see
pep.Just for this exact use case :P
lnjhas left
SamWhitedBut 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
peterMy 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
SamWhitedAgreed; that's probably a good thing to do to reduce confusion.
peterPrecisely.
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
MarandaSignature 32 bytes, Proof 20 bytes
Maranda>.>
MarandaSamWhited, that doesn't look right
Maranda(what Conversations does)
alexishas joined
alexishas left
Guushas left
Guushas joined
Dave Cridlandhas left
alexishas joined
SamWhitedI'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?)
XSF Discussion - 2018-09-24