-
pep.
jonasw, I think it's *"Trainer\*Innen"* :P
-
pep.
(Hopefully your client doesn't already convert what I just wrote)
-
pep.
This "I want to change XHTML-IM" fashion is going really quick and I don't like that
-
pep.
I'm really curious as to what is going to come out of that new markdown-y spec. But I don't expect much
-
Zash
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
-
pep.
Certainly
-
pep.
/popcorn
-
pep.
And we would have lost a few weeks for nothing
-
pep.
Weeks of talking, months of incompatibilities, yeras of ranting✎ -
pep.
Weeks of talking, months of incompatibilities, years of ranting✎ ✏ -
pep.
Weeks of talking, months of ranting, years of incompatibilities ✏
-
pep.
Or are we ever really done ranting
-
Zash
pep.: When we die
-
moparisthebest
Just for Zash I'll write a bot with a dead mans switch to rant in here after I die
-
Flow
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
-
Zash
Flow: Pick the first markdown library you can find and try?
-
Flow
Zash: Is that challenging me to do a evaluation of the situation or so that I see the very first lib I pick failing? ;)
-
Zash
Since the original implementation does html passthough, I suspect it to be highly likely that it be the default.
-
Flow
Ok, but then what do all the sites displaying HTML generated from CommonMark do?
-
Zash
Even pandoc, the glorious saviour of all markup, defaults to html right through
-
Flow
Is it probably more a matter of unsafe defaults?
-
Zash
Defaults matter.
-
Flow
Course
-
Flow
https://github.com/commonmark/cmark#security
-
Flow
by default we will do the unsafe thing because convenience
-
pep.
Yay
-
Zash
If we could just invent some sufficiently complicated to get wrong XML format...
-
Flow
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
-
dwd
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.
-
Flow
dwd: whut? the idea has always been that ISR is used to authenticate the resumption
-
dwd
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.
-
Flow
dwd: caused by the service, for some reason, "forgetting" the isr token, e.g. because of a restart
-
Flow
i.e. a fallback to "full" SASL auth, instead of lightweight ISR auth
-
dwd
Flow, So you're advocating a user enumeration attack? :-)
-
dwd
ISR is not, and must not be, authentication. We went through this I don't know how many times.
-
Zash
Does the token contain the username?
-
Flow
dwd: It's authenticating the stream resumption, I don't know how many times we went through this
-
Flow
Zash, no
-
dwd
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.
-
dwd
Flow, So ISR+SCRAM is valid (just more round-trips). But also ISR+EXTERNAL, which is entirely reasonable.
-
Flow
sure, but ISR alone is also an option
-
dwd
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.
-
Flow
also, I don't see how one could do ISR + another SASL mech, after xep388 moved away from multi SASL mechs to 'tasks'
-
dwd
Well, because ISR isn't a SASL mech to begin with.
-
Flow
but SASL-HT is
-
Flow
and ISR is based on it
-
dwd
Sure. But HT-* is *just* a SASL mechanism that you *could* use with ISR, surely?
-
Flow
so it's SASL-HT+SCRAM what you are suggesting
-
Flow
dwd: no
-
dwd
Well, then, the design is wrong.
-
Flow
I don't think so, but please elaborate
-
dwd
Flow, If you can't use resume a session when authenticating using, say, EXTERNAL, the design is clearly wrong.
-
dwd
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.
-
Flow
well that was possible until you switched xep388 from chained SASL mechs to tasks
-
dwd
No, that's rubbish.
-
Flow
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
-
dwd
That does not make sense. HT-* *is* a SASL mechanism.
-
dwd
So why would you need to use it *with* anything else?
-
Flow
The initial idea of our SASL2 was to make it possible to chain multiple SASL mechs
-
dwd
No it wasn't. I know this because the initial idea was mine.
-
Flow
maybe your idea was different, but the first versions of SASL2 did make it possible to chain SASL mechs
-
dwd
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.
-
Flow
and I still think they should be
-
Flow
but that's mostly unrelaeted to this discussion I think
-
dwd
Well, I tried it, and they can't.
-
Flow
well maybe a sample of one is not enough
-
Flow
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-*
-
dwd
Well, that's rather my point - no it isn't. There's no reason why ISR needs to be tied to HT-*.
-
Flow
the only other mechanism suitable is probably EXTERNAL
-
Flow
I don't see the point in ISR + SCRAM
-
Flow
becasue then you could do simply standard SM resumption and SCRAM
-
dwd
Sure. But ISR+SCRAM will be substantially fewer round-trips.
-
dwd
Just one more, actually, than ISR+HT-*.
-
Flow
and I doubt if ISR+HT-* is substantially weaker then ISR+EXTERNAL
-
Flow
or any other mech
-
dwd
Flow, You're deluded if you think that's the case.
-
Flow
If the lifetime of the hashed token is limited?
-
dwd
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.
-
dwd
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.
-
Flow
I think everything is off as soon as an attacker is able to obtain things from the service
-
Zash
dwd: an attacker with access to server internals?
-
Flow
of course, you could argue that an attacker possibly has only access to some server internals and so
-
dwd
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.
-
Flow
I hope that no one stores the HT-* in a database, should be small enough to hold it in memory
-
jonasw
clustering?
-
Flow
and probably something I should write into the I-D
-
jonasw
somebody will do that
-
Flow
jonasw, clustering doesn't automatically mean that you have to store the token in a db
-
Flow
but of course, somebody will do something unreasonable
-
jonasw
sure, but it may be the convenient choice
-
Flow
damn you, convenience
-
dwd
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.
-
Flow
dwd, sorry didn't get the last part
-
Flow
If i'm not mistaken nothing in the current ISR ProtoXEP currently limits the mech to HT-*
-
dwd
Well, we need to fix that then.
-
Flow
but of course, it's written with HT-* in mind
-
Flow
dwd, fix what?
-
Flow
I'm currently more worried how much more complex the SASL2-ISR combination is, compared to my initial ISR ProtoXEP…
-
jonasw
how many round-trips does ISR save if you use any other SASL mechanism?
-
Flow
Altough I believe in Holger to implement any complex beast in ejabberd :)
-
jonasw
i.e. what’s the difference to just resuming in that case?
-
Flow
jonasw, IIRC 1 round-trip
-
Flow
but I haven't counted recently
-
Flow
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
-
Flow
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"
-
Kev
FWIW, I think dwd's right about just about everything above.
-
Flow
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
-
pep.
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
-
pep.
(i.e., doesn't fit in the color theme)
-
edhelas
is there a place where I can find a proper way to detect if a JID is valid or not ?
-
mathieui
the RFC? :p
-
pep.
https://tools.ietf.org/html/rfc7564
-
pep.
I don't know of tools doing that
-
edhelas
sure, but is there some nice PRECIS/regex thing that I can reuse ?
-
pep.
I don't think it's a one regex job :x
-
pep.
But I've never ever read it. Maybe implementations have examples✎ -
pep.
But I've neven ever read it. Maybe implementations have examples✎ ✏ -
edhelas
https://github.com/movim/movim/issues/492 got that, don't know how to fix it
-
pep.
But I've never even read it. Maybe implementations have examples ✏
-
pep.
I think I linked a lib doing PRECIS in php the other day
-
pep.
https://github.com/tom--/precis I don't know how compliant that is though
-
lskdjf
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...
-
SamWhited
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.