what could also be is that the xml lib of dino prints this wrong
lovetox
but i guess less likely as it would have to happen with all stanzas then
lovetox
really weird bug
efrithas left
labdsfhas left
labdsfhas joined
edhelashas left
edhelashas joined
olihas joined
olihas joined
lnjhas left
thorstenhas left
UsLhas left
thorstenhas joined
UsLhas joined
olihas joined
olihas joined
Neustradamus
It is possible to add new SCRAM in next XMPP Compliance Suites?
lovetoxhas left
efrithas joined
waqashas left
waqashas joined
olihas left
olihas left
olihas joined
waqashas left
waqashas joined
lumihas left
waqashas left
waqashas joined
waqashas left
waqashas joined
waqashas left
waqashas joined
waqashas left
waqashas joined
doshas left
pep.has left
waqashas left
waqashas joined
waqashas left
waqashas joined
waqashas left
waqashas joined
waqashas left
waqashas joined
waqashas left
waqashas joined
lnjhas left
waqashas left
waqashas joined
waqashas left
olihas joined
lnjhas left
vanitasvitaehas left
lnjhas joined
Zashhas left
lnjhas left
ThibGhas left
ThibGhas joined
efrithas left
edhelashas left
alacerhas joined
moparisthebesthas left
Tobiashas joined
Tobiashas joined
MattJhas left
moparisthebesthas left
ThibGhas left
ThibGhas joined
chunkhas left
chunkhas joined
ThibGhas left
ThibGhas joined
moparisthebesthas joined
moparisthebesthas left
Yagizahas joined
moparisthebesthas joined
moparisthebesthas left
moparisthebesthas left
moparisthebesthas left
moparisthebesthas left
moparisthebesthas joined
Nekithas joined
moparisthebesthas joined
Zashhas left
moparisthebesthas left
moparisthebesthas joined
moparisthebesthas joined
moparisthebesthas left
moparisthebesthas left
erkanfileshas left
Nekithas left
Nekithas joined
chunkhas left
chunkhas joined
ThibGhas joined
ThibGhas joined
Yagizahas left
sezuanhas left
waqashas joined
alacerhas left
moparisthebesthas joined
lorddavidiiihas joined
frainzhas left
frainzhas joined
lhas joined
neshtaxmpphas left
neshtaxmpphas left
lorddavidiiihas left
lorddavidiiihas joined
olihas joined
olihas left
olihas left
olihas joined
lorddavidiiihas left
jjrhhas left
waqashas left
Sevehas left
lorddavidiiihas joined
jjrhhas left
waqashas joined
mrDoctorWhohas joined
olihas left
olihas joined
lovetoxhas joined
alacerhas joined
genofirehas left
genofirehas joined
Wiktor
> I thought "xmlns='urn:xmpp:bob'" would be illegal.
Xml namespaces are URIs but practically any XML lib treats them as strings anyway (no validation). In your case the namespace is URN, colons are frequent in URNs :) (check out Wikipedia)
moparisthebesthas joined
moparisthebesthas joined
waqashas left
edhelashas joined
alacerhas left
alacerhas joined
Yagizahas joined
edhelashas left
edhelashas joined
waqashas joined
alacerhas left
!xsf_Martinhas joined
edhelashas left
edhelashas joined
!xsf_Martinhas left
!xsf_Martinhas joined
!xsf_Martinhas left
edhelashas left
edhelashas joined
lskdjfhas joined
chunkhas left
marc_has joined
alacerhas joined
Yagizahas left
danielhas joined
waqashas left
lhas left
lhas joined
Fahrgasthas left
Fahrgasthas joined
Fahrgasthas left
lhas left
lhas joined
vaulorhas joined
marc_has left
jonas’
huh
jonas’
vanitasvitae, that bug sounds familiar
jonas’
daniel, see above, I think you had the same thing the other day?
Nekithas left
Nekithas joined
jonas’
vanitasvitae, what you’re seeing there sounds very much like what daniel had in https://github.com/siacs/Conversations/issues/3315
jonas’
there seems to be some ejabberd bug there
vanitasvitae
jonas’: thanks for the link
jonas’
Neustradamus, new SCRAM? what are you talking about?
Guushas left
efrithas joined
vinx55has joined
lhas joined
lhas joined
lhas joined
lovetox
SCRAM-256
jonas’
are the weakened security properties of SHA-1 relevant for SCRAM?
Zash
Nope
jonas’
then I don’t think it’s worth the trouble
Zash
Not that I know of at least
Zash
IIRC even HMAC-SHA1 is fine for things that HMACs are appropriate for
lskdjfhas joined
Zash
So yeah, combined with that you can't convert the hashes, it's not really worth it
lovetox
why was it then specified?
jonas’
for new deployments probably
Zash
Hm?
lovetox
but why if it doesnt increase security
jonas’
but in existing deployments, migrating the SCRAM version is a PITA -- you need a password change to achieve that
jonas’
safe is better than sorry?
lovetox
hm not really convincing ..
Zash
Why use modern crypto?
lovetox
This document registers the SASL mechanisms SCRAM-SHA-256 and SCRAM-
SHA-256-PLUS. SHA-256 has stronger security properties than SHA-1,
and it is expected that SCRAM mechanisms based on it will have
greater predicted longevity than the SCRAM mechanisms based on SHA-1.
lovetox
seems to be it does play indeed a role and is relevant
Zash
> SHA-256 has stronger security properties than SHA-1,
This is true.
Zash
But whether that matters for how they are used in SCRAM is something different
lovetox
does not make much sense to specify a hash with great seurity properties, if you dont need these properties at all
pep.
Just like ipv6 was specified in the past, and still not used in the present, maybe someday in the future..
Zash
The real question is why not just wait for SCRAM-SHA-3
jonas’
See [RFC4270] and [RFC6194] for reasons to move from SHA-1 to a
strong security mechanism like SHA-256.
jonas’
hah
Zash
What do they say?
jonas’
TL;DR (yet)
Zash
Attacks on Cryptographic Hashes in Internet Protocols
Ctrl-F "HMAC" - 0 matches
jonas’
3.3. HMAC-SHA-1
As of today, there is no indication that attacks on SHA-1 can be
extended to HMAC-SHA-1.
Zash
lovetox: it's an improvement, but relatively small improvement.
lovetox
yeah probably :)
jonas’
I’m composing a question on crypto.stackexchange about this
Zash
Remember that the state of the art before SCRAM was DIGEST-MD5 and storing plain text passwords.
Zash
DIGEST-MD5 -> SCRAM is a huge improvement all around
Zash
SCRAM-SHA-1 -> SCRAM-SHA-256 is a small improvement that would cost a lot for existing deployments
mightyBroccolihas joined
Zash
Converting plain text passwords to hashed form is easy. Converting hashed form to a different hashed form is Hard
alacerhas left
lovetox
im not arguing for or against this new standard, it just was a contradiction to me that the ietf goes through the motion of making a new standard with a more expensive hash method, if it has no effect at all on security
lovetox
maybe it was "better save than sorry" but bringing such a standard to live seems to me a bit of work that nobody would do just because he feels like 256 is a prettier number
Zash
not no effect, it's better. but not enough better to outweight the cost of switching
lovetox
yeah you are probably right on that
vinx55has left
lovetox
it is though really easy to implement if you already have a SHA1 impl
Zash
depends
Zash
In theory it's just replacing the hash function
Zash
So if you have code that makes that easy then it's easy
jonas’
there we go https://crypto.stackexchange.com/q/66195/16902
rionhas joined
lovetox
great writeup :)
Zash
There's one spot in SCRAM where it uses bare SHA-1 tho, for converting the ClientKey into StoredKey
Zash
StoredKey := H(ClientKey)
jonas’
oh, I missed that
jonas’
but storedkey is never transferred and only used as key in the hmac
Zash
But ClientKey is HMAC output and not combined with anything
rion
Does any XEP describe disco#info get requests with non-empty query element? Just found this in iris code w/o any reference to specs.
olihas left
olihas joined
Zash
rion: I think there's something like disco-subscriptions somewhere, but I'm not sure if there's a XEP
olihas left
rion
I see xep-0230 but there is disco#items
rion
Ok, thanks Zash. I'll put it under #if 0 for now
alacerhas joined
matlaghas left
lumihas joined
lnjhas joined
UsLhas left
UsLhas joined
oli
didn't we had the sha-256 discussion before? or was it at ejabberd?
Zashhas left
danielhas left
danielhas joined
lhas left
chunkhas left
!xsf_Martinhas joined
chunkhas joined
MattJhas joined
lskdjfhas joined
half-shot_has joined
rionhas left
Kevhas joined
ThibGhas joined
ThibGhas joined
Ge0rGhas left
!xsf_Martinhas left
!xsf_Martinhas joined
lhas joined
Ge0rG
rion: IIRC it is also used in MIX to distinguish between MUC protocol and MIX protocol, but maybe it was disco#items as well
jonas’
Ge0rG, no
jonas’
MIX uses the node for that
jonas’
*used
jonas’
you confuse that with the roster query
jonas’
so I’ve been thinking about MUC self ping. thinking about it, using a silent, non-archived <message/> might actually be the most traffic-efficient way to do it.
Ge0rG
jonas’: wasn't there disco#items on the MIX room JID to get a list of all nodes?
Ge0rG
jonas’: a message to whom?
jonas’
Ge0rG, through the MUC
jonas’
so to everyone, essentially
Ge0rG
jonas’: to the MUC?
Ge0rG
How's that more traffic efficient?
jonas’
it is a ping for everyone. only one needs to send it, everyone else also learns that they themselves are still connected.✎
jonas’
it is a ping for everyone. only one client needs to send it, everyone else also learns that they themselves are still connected. ✏
jonas’
so it saves sending the ping for everyone but one client.
lorddavidiiihas left
jonas’
Ge0rG, MIX uses @node='mix' to qualify that; no need for child elements on the <{…disco#items}query/>
jonas’
back to muc self-ping: if everyone implements it with "after N+random(-1, 1) minutes of no message received through the MUC, send a ping <message/>; if after N+M (M>2) minutes no message was received, conclude that we’re disconnected", the one with the lowest random() output will be the one who sends the pings, and everyone else silently benefits from it.
jonas’
does that make sense?
lovetox
sounds weird, but somehow i like it
lovetox
wonder if this has any downsides
Ge0rG
jonas’: provided that we can normalize N. Also there might be minor inefficiency when multiple clients roll the same number. But I fear there will be clients making a short cut and not checking for the last incoming message, just sending anyway
jonas’
potential downsides: if the MUC eats the <message/> (because it’s bodyless or whatever), it breaks. if the MUC archives the message, it pollutes the archive massively.
jonas’
Ge0rG, slap those clients then.
lovetox
there are store hints for exactly that usecase
lovetox
and bodyless is no problem in any muc
jonas’
lovetox, it may be with biboumi
jonas’
but I think even biboumi simply reflects those on the XMPP side and drops them on the IRC side
Ge0rG
jonas’: but how is it better than the 0410 proposal?
jonas’
Ge0rG, 1. it requires no server-side implementation; 2. in my specific implementation, it is easier to keep multiple <messages/> in flight and have a catch-all handler for the replies than with IQs (because IQs are request-response, and each in-flight IQ needs an entry in the response handler table -> memory use); 3. what happens when you send a message to a MUC you’re not joined to is more well-defined than IQ, 4. no race conditions with nickname changes or whatever
lovetox
the self ping has on its positive side that its easier to implement
Ge0rG
Also it might make sense to have different N for mobile vs desktop clients, and your suggestion ends up with `min(N) ` over all participants
jonas’
(I don’t find it easier to implement, see (2) above)
Ge0rG
jonas’: some MUCs allow messages from non participants. What now?
jonas’
Ge0rG, that’s a true point. For what it’s worth, a MUC implementation could still not forward the message to all participants but only reflect it to the sending client, if we find that it’s a battery hog.
jonas’
Ge0rG, eh, why :D
jonas’
I think with that, my proposal falls down the drain
jonas’
good that we talked about it though
Ge0rG
jonas’: don't know why. Also some bridge implementations (looking at you, biboumi) will accept a message from a non joined resource of a joined user
lovetox
it is jonas in my opinion, one is just send an iq and wait for response, the other is, check messages for something then start a timer that i have to reset on the next message, and deal with over multiple scenarios like disconnect etc
jonas’
lovetox, how long do you wait for a response for the IQ?
lovetox
lots of space to have bugs
jonas’
no, you don’t need ot check messages for something
jonas’
*every* message you receive lets you know you’re joined
jonas’
you need that timer anyways if you want to implement self-ping efficiently.
jonas’
you don’t need to send a ping when you just received a message from the MUC.
lovetox
hm yeah
lovetox
seems similar
jonas’
(hint: the same thing goes for your main xml stream ;-))
jonas’
problem with the IQ ping is the timeout
jonas’
using a long timeout has the downside that if the MUC was temporarily blackholed, you have to wait very long until you can resync
jonas’
using a short timeout has the downside that you won’t resync automatically in a high-latency situation.
ThibGhas joined
jonas’
using multiple interleaved pings with long timeout has the memory cost issue
Ge0rG
jonas’: on timeout you should just mark the MUC as not responding, and schedule a new ping
jonas’
Ge0rG, that’s obvious
Ge0rG
No need to have multiple interleaving pings
jonas’
which timeout should I use for the ping then?
lorddavidiiihas joined
lovetox
i dont know what you are talking about memory, a timeout, compared to a full fletched gui client Oo
jonas’
lovetox, aioxmpp might very well be used for a bot which runs ~forever and if it loses connectivity which isn’t restored, I don’t want it to turn into a memory hog
jonas’
I don’t like ever-growing tables.
jonas’
(and by "loses connectivity" I mean "a MUC in which it is joined becomes blackholed")
Ge0rG
jonas’: have a ping timeout of 60s and a ping interval of 10m after the last activity
half-shot_has left
jonas’
Ge0rG, so if my link has a latency higher than 60s, I don’t ever resync to the MUC; it is "not responding" forever.
Ge0rG
jonas’: correct.
jonas’
meh.
Ge0rG
Make it configurable for the military satellite use case
jonas’
me not likey
jonas’
lovetox, by the way, XEP-0410 even tells you to not self-ping unless the MUC is silent:
> After an adequate amount of silence from a given MUC (e.g. 15 minutes), or from all MUCs from a given service domain, a client should initiate a self-ping.
lovetox
i just dont like timers, i pass a callback to some timer api, and later it comes back and bites me, either because the object for the callback is not there anymore, or because i forgot to cancel the timer if any of X events happen
Ge0rG
Yeah
jonas’
which is why I wrapped this specific logic (which I already needed for the main xml stream anyways) in a class which takes care of handling the timer
jonas’
I just should "nevermind, I got data!" at that class from time to time, and when I don’t do that, it’ll tell me "hey, no data for X time, wanna do something about that?"✎
jonas’
I just shout "nevermind, I got data!" at that class from time to time, and when I don’t do that, it’ll tell me "hey, no data for X time, wanna do something about that?" ✏
Zash
Prosody has something like that too.
jonas’
so I can be reasonably confident that when that event triggers, something is wrong
lovetox
you just described a callback...
lovetox
i think we all know how this works
jonas’
lovetox, typical callback APIs are a bit more convoluted than that though
jonas’
(also, this has in fact two timers, a soft and a hard timeout)
jonas’
you normally need to store some handle and exchange that whenever you re-set the timer
jonas’
but that’s implementation details
jonas’
I’m just saying one can make this rather painless
!xsf_Martinhas left
!xsf_Martinhas joined
lovetox
its painless if you have not many events that need the timer to be deleted, like an xml stream, what is there, essentially disconnect() thats the only event where you stop the timer
jonas’
same goes for a MUC room. "leave" is the only thing where you stop the timer.
lovetox
think about chatstates, i have a inactive timer, it has to be reset whener the mouse moves over the window, if i switch the window, if i close the window, if i disconnect, etc this goes on and on
lovetox
but yeah, i see it depends on what you do with the timer