-
vanitasvitae
I think I'm on a tagged version
-
vanitasvitae
Have to upgrade soon anyways ;D
-
lovetox
hm one moment
-
lovetox
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
-
Neustradamus
It is possible to add new SCRAM in next XMPP Compliance Suites?
-
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)
-
jonas’
huh
-
jonas’
vanitasvitae, that bug sounds familiar
-
jonas’
daniel, see above, I think you had the same thing the other day?
-
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?
-
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
-
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
-
Zash
Converting plain text passwords to hashed form is easy. Converting hashed form to a different hashed form is Hard
-
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
-
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
-
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.
-
Zash
rion: I think there's something like disco-subscriptions somewhere, but I'm not sure if there's a XEP
-
rion
I see xep-0230 but there is disco#items
-
rion
Ok, thanks Zash. I'll put it under #if 0 for now
-
oli
didn't we had the sha-256 discussion before? or was it at ejabberd?
-
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.
-
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.
-
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?
-
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
-
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
-
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
-
lovetox
:)
-
Neustradamus
jonas’: https://tools.ietf.org/html/rfc7677 + https://tools.ietf.org/html/draft-ietf-mile-xmpp-grid-08
-
vanitasvitae
Happy new year!
-
pep.
Happy public domain day
-
jonas’
happy new year’s from CET https://sotecware.net/images/dont-puush-me/WVeQE5W9eDNjekWpVcI5J0z5i6kPBYXRJTHfxKQ_DF0.png✎ -
jonas’
happy new year from CET https://sotecware.net/images/dont-puush-me/WVeQE5W9eDNjekWpVcI5J0z5i6kPBYXRJTHfxKQ_DF0.png ✏
-
waqas
pep.: I didn't realize that was a thing. Looks like "Yes! We Have No Bananas" is now in the public domain, https://www.youtube.com/watch?v=PDd8shcLvHI
-
waqas
There seems to be a list here: https://lifehacker.com/these-1923-copyrighted-works-enter-the-public-domain-in-1825241296
-
Seve
Happy new year! :)