XSF Discussion - 2017-10-15

jonasw, I think it's *"Trainer\*Innen"* :P

(Hopefully your client doesn't already convert what I just wrote)

This "I want to change XHTML-IM" fashion is going really quick and I don't like that

I'm really curious as to what is going to come out of that new markdown-y spec. But I don't expect much

pep.: People will run a random markdown js lib over stuff, and there'll be a high chance that they pick one that defaults to passing html trough and then we're back at square 1

Certainly

/popcorn

And we would have lost a few weeks for nothing

Weeks of talking, months of ranting, years of incompatibilities ✏

Or are we ever really done ranting

pep.: When we die

Just for Zash I'll write a bot with a dead mans switch to rant in here after I die

Zash: I'm not sure if that most "markup to HTML" converter libs would pass html trough, but I could be wrong. On the other hand: The whole stackexchange network, and things like discourse, are facing the same situation, and I've never heard that either of them was vulnerable to malicious HTML injection

Flow: Pick the first markdown library you can find and try?

Zash: Is that challenging me to do a evaluation of the situation or so that I see the very first lib I pick failing? ;)

Since the original implementation does html passthough, I suspect it to be highly likely that it be the default.

Ok, but then what do all the sites displaying HTML generated from CommonMark do?

Even pandoc, the glorious saviour of all markup, defaults to html right through

Is it probably more a matter of unsafe defaults?

Defaults matter.

Course

https://github.com/commonmark/cmark#security

by default we will do the unsafe thing because convenience

Yay

If we could just invent some sufficiently complicated to get wrong XML format...

dwd: does xep388 <failure/> have a way to tell the client to try it with a different SASL mech again? Or do we even have that in the standard SASL profile? asking because of ISR

Flow, ISR has - hopefully - nothing to do with that. Either you're authenticated or not, and if you're authenticated ISR will either succeed or not.

dwd: whut? the idea has always been that ISR is used to authenticate the resumption

Flow, But also, no. I'm not sure what would trigger that. The user exists but authentication failed? That case is normally treated equally to the user not existing for security reasons.

dwd: caused by the service, for some reason, "forgetting" the isr token, e.g. because of a restart

i.e. a fallback to "full" SASL auth, instead of lightweight ISR auth

Flow, So you're advocating a user enumeration attack? :-)

ISR is not, and must not be, authentication. We went through this I don't know how many times.

Does the token contain the username?

dwd: It's authenticating the stream resumption, I don't know how many times we went through this

Zash, no

Flow, ISR is just '198 resumption but as a '388 extension, right? The authentication happens within a normal SASL mechanism. You've proposed HT-* for this purpose, but one could use anything.

Flow, So ISR+SCRAM is valid (just more round-trips). But also ISR+EXTERNAL, which is entirely reasonable.

sure, but ISR alone is also an option

No, it isn't. I'm very sure we had this argument before. If you make ISR an authentication mechanism in its own right it should not be conducted within the XSF.

also, I don't see how one could do ISR + another SASL mech, after xep388 moved away from multi SASL mechs to 'tasks'

Well, because ISR isn't a SASL mech to begin with.

but SASL-HT is

and ISR is based on it

Sure. But HT-* is *just* a SASL mechanism that you *could* use with ISR, surely?

so it's SASL-HT+SCRAM what you are suggesting

dwd: no

Well, then, the design is wrong.

I don't think so, but please elaborate

Flow, If you can't use resume a session when authenticating using, say, EXTERNAL, the design is clearly wrong.

Since EXTERNAL is relying on (for example) a TLS certificate or session resumption, and HT-* is weaker, then by *allowing* HT-* you're weakening security.

well that was possible until you switched xep388 from chained SASL mechs to tasks

No, that's rubbish.

I'd say tha just HT-* is sufficently secure for some deployments, but if you want to use HT-* with a strong mech, then it should be possible to do this

That does not make sense. HT-* *is* a SASL mechanism.

So why would you need to use it *with* anything else?

The initial idea of our SASL2 was to make it possible to chain multiple SASL mechs

No it wasn't. I know this because the initial idea was mine.

maybe your idea was different, but the first versions of SASL2 did make it possible to chain SASL mechs

The idea was to have an extensible SASL profile that could have secondary authentication includedm like 2FA. I thought (wrongly) these oculd be modelled as SASL mechanisms.

and I still think they should be

but that's mostly unrelaeted to this discussion I think

Well, I tried it, and they can't.

well maybe a sample of one is not enough

but back to the topic: ISR is now based on SASL HT-*, and if xep388 doesn't allow chained SASL mechs (maybe additional to tasks), then it's ISR with HT-*, or standard SM resumption without SASL HT-*

Well, that's rather my point - no it isn't. There's no reason why ISR needs to be tied to HT-*.

the only other mechanism suitable is probably EXTERNAL

I don't see the point in ISR + SCRAM

becasue then you could do simply standard SM resumption and SCRAM

Sure. But ISR+SCRAM will be substantially fewer round-trips.

Just one more, actually, than ISR+HT-*.

and I doubt if ISR+HT-* is substantially weaker then ISR+EXTERNAL

or any other mech

Flow, You're deluded if you think that's the case.

If the lifetime of the hashed token is limited?

HT-* is, at its core, just a hash of a plaintext token held on the server in the clear. That immediately means an attacker can obtain that token and use it, potentially.

That's not a bad thing, because we can mitigate that with limited lifetime etc. But to think it offers the same level of security as a client certificate is really not right at all.

I think everything is off as soon as an attacker is able to obtain things from the service

dwd: an attacker with access to server internals?

of course, you could argue that an attacker possibly has only access to some server internals and so

Zash, an attacker with access to the database, probably. Typical breach. And yes, you could handwave over keeping the tokens out of persistent storage etc.

I hope that no one stores the HT-* in a database, should be small enough to hold it in memory

clustering?

and probably something I should write into the I-D

somebody will do that

jonasw, clustering doesn't automatically mean that you have to store the token in a db

but of course, somebody will do something unreasonable

sure, but it may be the convenient choice

damn you, convenience

Flow, But anyway, the point is that if ISR works with *any* SASL mechanism in principle, then if HT-* is a problem we just use something else.

dwd, sorry didn't get the last part

If i'm not mistaken nothing in the current ISR ProtoXEP currently limits the mech to HT-*

Well, we need to fix that then.

but of course, it's written with HT-* in mind

dwd, fix what?

I'm currently more worried how much more complex the SASL2-ISR combination is, compared to my initial ISR ProtoXEP…

how many round-trips does ISR save if you use any other SASL mechanism?

Altough I believe in Holger to implement any complex beast in ejabberd :)

i.e. what’s the difference to just resuming in that case?

jonasw, IIRC 1 round-trip

but I haven't counted recently

dwd, I think we talked past each other, for most of the time. Which made us didn't talk about what should happen if HT-* failes because of an experied token (my initial question). In that sense, it is probably different than most SASL mechs, in the sense that you could fallback to another SASL mech

prably the simplest approach would be "client knows that he just did a HT-* auth that failed, so let's retry (possible on a new connection) e.g. SCRAM"

FWIW, I think dwd's right about just about everything above.

sure, was mostly a misunderstanding what ISR+SASL-MECH means. He was talking about using ISR with SASL-MECH, and I was talking about using ISR with SASL HT-* and SASL-MECH chained

hmm, I was wondering about Consistent Color Generation. I remember we were talking about XHTML-IM styles/colors the other day, I suppose it's the same issue here? edhelas

(i.e., doesn't fit in the color theme)

is there a place where I can find a proper way to detect if a JID is valid or not ?

the RFC? :p

https://tools.ietf.org/html/rfc7564

I don't know of tools doing that

sure, but is there some nice PRECIS/regex thing that I can reuse ?

I don't think it's a one regex job :x

https://github.com/movim/movim/issues/492 got that, don't know how to fix it

But I've never even read it. Maybe implementations have examples ✏

I think I linked a lib doing PRECIS in php the other day

https://github.com/tom--/precis I don't know how compliant that is though

edhelas, why would a client need to validate jids (perfectly)? the client would only need to forward everything to the server and let the validation be done there. There is the point that it might be convinient to show a user that what they are doing definitly won't work, but that check mainly should not have false negatives - false positives aren't so bad because the server will detect them. so in practice .+@.+ should work fine...

edhelas: I've got a validator you can use somewhere if you still need one. I'll seems it your way when I'm next at my desk.