XSF Discussion - 2018-12-31

I think I'm on a tagged version

Have to upgrade soon anyways ;D

hm one moment

what could also be is that the xml lib of dino prints this wrong

but i guess less likely as it would have to happen with all stanzas then

really weird bug

It is possible to add new SCRAM in next XMPP Compliance Suites?

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

huh

vanitasvitae, that bug sounds familiar

daniel, see above, I think you had the same thing the other day?

vanitasvitae, what you’re seeing there sounds very much like what daniel had in https://github.com/siacs/Conversations/issues/3315

there seems to be some ejabberd bug there

jonas’: thanks for the link

Neustradamus, new SCRAM? what are you talking about?

SCRAM-256

are the weakened security properties of SHA-1 relevant for SCRAM?

Nope

then I don’t think it’s worth the trouble

Not that I know of at least

IIRC even HMAC-SHA1 is fine for things that HMACs are appropriate for

So yeah, combined with that you can't convert the hashes, it's not really worth it

why was it then specified?

for new deployments probably

Hm?

but why if it doesnt increase security

but in existing deployments, migrating the SCRAM version is a PITA -- you need a password change to achieve that

safe is better than sorry?

hm not really convincing ..

Why use modern crypto?

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.

seems to be it does play indeed a role and is relevant

> SHA-256 has stronger security properties than SHA-1, This is true.

But whether that matters for how they are used in SCRAM is something different

does not make much sense to specify a hash with great seurity properties, if you dont need these properties at all

Just like ipv6 was specified in the past, and still not used in the present, maybe someday in the future..

The real question is why not just wait for SCRAM-SHA-3

See [RFC4270] and [RFC6194] for reasons to move from SHA-1 to a strong security mechanism like SHA-256.

hah

What do they say?

TL;DR (yet)

Attacks on Cryptographic Hashes in Internet Protocols Ctrl-F "HMAC" - 0 matches

3.3. HMAC-SHA-1 As of today, there is no indication that attacks on SHA-1 can be extended to HMAC-SHA-1.

lovetox: it's an improvement, but relatively small improvement.

yeah probably :)

I’m composing a question on crypto.stackexchange about this

Remember that the state of the art before SCRAM was DIGEST-MD5 and storing plain text passwords.

DIGEST-MD5 -> SCRAM is a huge improvement all around

SCRAM-SHA-1 -> SCRAM-SHA-256 is a small improvement that would cost a lot for existing deployments

Converting plain text passwords to hashed form is easy. Converting hashed form to a different hashed form is Hard

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

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

not no effect, it's better. but not enough better to outweight the cost of switching

yeah you are probably right on that

it is though really easy to implement if you already have a SHA1 impl

depends

In theory it's just replacing the hash function

So if you have code that makes that easy then it's easy

there we go https://crypto.stackexchange.com/q/66195/16902

great writeup :)

There's one spot in SCRAM where it uses bare SHA-1 tho, for converting the ClientKey into StoredKey

StoredKey := H(ClientKey)

oh, I missed that

but storedkey is never transferred and only used as key in the hmac

But ClientKey is HMAC output and not combined with anything

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.

rion: I think there's something like disco-subscriptions somewhere, but I'm not sure if there's a XEP

I see xep-0230 but there is disco#items

Ok, thanks Zash. I'll put it under #if 0 for now

didn't we had the sha-256 discussion before? or was it at ejabberd?

rion: IIRC it is also used in MIX to distinguish between MUC protocol and MIX protocol, but maybe it was disco#items as well

Ge0rG, no

MIX uses the node for that

*used

you confuse that with the roster query

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.

jonas’: wasn't there disco#items on the MIX room JID to get a list of all nodes?

jonas’: a message to whom?

Ge0rG, through the MUC

so to everyone, essentially

jonas’: to the MUC?

How's that more traffic efficient?

it is a ping for everyone. only one client needs to send it, everyone else also learns that they themselves are still connected. ✏

so it saves sending the ping for everyone but one client.

Ge0rG, MIX uses @node='mix' to qualify that; no need for child elements on the <{…disco#items}query/>

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.

does that make sense?

sounds weird, but somehow i like it

wonder if this has any downsides

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

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.

Ge0rG, slap those clients then.

there are store hints for exactly that usecase

and bodyless is no problem in any muc

lovetox, it may be with biboumi

but I think even biboumi simply reflects those on the XMPP side and drops them on the IRC side

jonas’: but how is it better than the 0410 proposal?

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

the self ping has on its positive side that its easier to implement

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

(I don’t find it easier to implement, see (2) above)

jonas’: some MUCs allow messages from non participants. What now?

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.

Ge0rG, eh, why :D

I think with that, my proposal falls down the drain

good that we talked about it though

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

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

lovetox, how long do you wait for a response for the IQ?

lots of space to have bugs

no, you don’t need ot check messages for something

*every* message you receive lets you know you’re joined

you need that timer anyways if you want to implement self-ping efficiently.

you don’t need to send a ping when you just received a message from the MUC.

hm yeah

seems similar

(hint: the same thing goes for your main xml stream ;-))

problem with the IQ ping is the timeout

using a long timeout has the downside that if the MUC was temporarily blackholed, you have to wait very long until you can resync

using a short timeout has the downside that you won’t resync automatically in a high-latency situation.

using multiple interleaved pings with long timeout has the memory cost issue

jonas’: on timeout you should just mark the MUC as not responding, and schedule a new ping

Ge0rG, that’s obvious

No need to have multiple interleaving pings

which timeout should I use for the ping then?

i dont know what you are talking about memory, a timeout, compared to a full fletched gui client Oo

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

I don’t like ever-growing tables.

(and by "loses connectivity" I mean "a MUC in which it is joined becomes blackholed")

jonas’: have a ping timeout of 60s and a ping interval of 10m after the last activity

Ge0rG, so if my link has a latency higher than 60s, I don’t ever resync to the MUC; it is "not responding" forever.

jonas’: correct.

meh.

Make it configurable for the military satellite use case

me not likey

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.

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

Yeah

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

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?" ✏

Prosody has something like that too.

so I can be reasonably confident that when that event triggers, something is wrong

you just described a callback...

i think we all know how this works

lovetox, typical callback APIs are a bit more convoluted than that though

(also, this has in fact two timers, a soft and a hard timeout)

you normally need to store some handle and exchange that whenever you re-set the timer

but that’s implementation details

I’m just saying one can make this rather painless

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

same goes for a MUC room. "leave" is the only thing where you stop the timer.

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

but yeah, i see it depends on what you do with the timer

:)

jonas’: https://tools.ietf.org/html/rfc7677 + https://tools.ietf.org/html/draft-ietf-mile-xmpp-grid-08

Happy new year!

Happy public domain day

happy new year from CET https://sotecware.net/images/dont-puush-me/WVeQE5W9eDNjekWpVcI5J0z5i6kPBYXRJTHfxKQ_DF0.png ✏

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

There seems to be a list here: https://lifehacker.com/these-1923-copyrighted-works-enter-the-public-domain-in-1825241296

Happy new year! :)