XSF Discussion - 2017-10-15


  1. pep.

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

  2. pep.

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

  3. pep.

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

  4. 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

  5. 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

  6. pep.

    Certainly

  7. pep.

    /popcorn

  8. pep.

    And we would have lost a few weeks for nothing

  9. pep.

    Weeks of talking, months of incompatibilities, yeras of ranting

  10. pep.

    Weeks of talking, months of incompatibilities, years of ranting

  11. pep.

    Weeks of talking, months of ranting, years of incompatibilities

  12. pep.

    Or are we ever really done ranting

  13. Zash

    pep.: When we die

  14. moparisthebest

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

  15. 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

  16. Zash

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

  17. 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? ;)

  18. Zash

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

  19. Flow

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

  20. Zash

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

  21. Flow

    Is it probably more a matter of unsafe defaults?

  22. Zash

    Defaults matter.

  23. Flow

    Course

  24. Flow

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

  25. Flow

    by default we will do the unsafe thing because convenience

  26. pep.

    Yay

  27. Zash

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

  28. 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

  29. 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.

  30. Flow

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

  31. 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.

  32. Flow

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

  33. Flow

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

  34. dwd

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

  35. dwd

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

  36. Zash

    Does the token contain the username?

  37. Flow

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

  38. Flow

    Zash, no

  39. 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.

  40. dwd

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

  41. Flow

    sure, but ISR alone is also an option

  42. 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.

  43. Flow

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

  44. dwd

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

  45. Flow

    but SASL-HT is

  46. Flow

    and ISR is based on it

  47. dwd

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

  48. Flow

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

  49. Flow

    dwd: no

  50. dwd

    Well, then, the design is wrong.

  51. Flow

    I don't think so, but please elaborate

  52. dwd

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

  53. 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.

  54. Flow

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

  55. dwd

    No, that's rubbish.

  56. 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

  57. dwd

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

  58. dwd

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

  59. Flow

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

  60. dwd

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

  61. Flow

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

  62. 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.

  63. Flow

    and I still think they should be

  64. Flow

    but that's mostly unrelaeted to this discussion I think

  65. dwd

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

  66. Flow

    well maybe a sample of one is not enough

  67. 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-*

  68. dwd

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

  69. Flow

    the only other mechanism suitable is probably EXTERNAL

  70. Flow

    I don't see the point in ISR + SCRAM

  71. Flow

    becasue then you could do simply standard SM resumption and SCRAM

  72. dwd

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

  73. dwd

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

  74. Flow

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

  75. Flow

    or any other mech

  76. dwd

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

  77. Flow

    If the lifetime of the hashed token is limited?

  78. 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.

  79. 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.

  80. Flow

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

  81. Zash

    dwd: an attacker with access to server internals?

  82. Flow

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

  83. 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.

  84. Flow

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

  85. jonasw

    clustering?

  86. Flow

    and probably something I should write into the I-D

  87. jonasw

    somebody will do that

  88. Flow

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

  89. Flow

    but of course, somebody will do something unreasonable

  90. jonasw

    sure, but it may be the convenient choice

  91. Flow

    damn you, convenience

  92. 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.

  93. Flow

    dwd, sorry didn't get the last part

  94. Flow

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

  95. dwd

    Well, we need to fix that then.

  96. Flow

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

  97. Flow

    dwd, fix what?

  98. Flow

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

  99. jonasw

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

  100. Flow

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

  101. jonasw

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

  102. Flow

    jonasw, IIRC 1 round-trip

  103. Flow

    but I haven't counted recently

  104. 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

  105. 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"

  106. Kev

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

  107. 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

  108. 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

  109. pep.

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

  110. edhelas

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

  111. mathieui

    the RFC? :p

  112. pep.

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

  113. pep.

    I don't know of tools doing that

  114. edhelas

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

  115. pep.

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

  116. pep.

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

  117. pep.

    But I've neven ever read it. Maybe implementations have examples

  118. edhelas

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

  119. pep.

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

  120. pep.

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

  121. pep.

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

  122. 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...

  123. 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.