XMPP Council - 2018-01-09

  1. Dave

    jonasw, SamWhited - Just running through the Council Agenda for tomorrow - is it only my two ProtoXEPs come in since last time?

  2. SamWhited

    Nothing new from me, just a few old things that have been festering

  3. daniel

    Dave: there is the Avatar conversion

  4. jonasw

    Dave, three, what daniel said

  5. Dave

    The state of isr-sasl2 seems confused - Council voted, that vote has presumably timed out, but no votes at all are recorded in Trello?

  6. Kev

    It wasn't clear to me which of the several versions of ISR we were voting on from the minutes. So I sent out a vote based on what I thought we were voting on, and a -1 otherwise.

  7. Dave

    Looks like Daniel, Kev and I all voted for.

  8. Dave

    Kev, I think his latest advertised is what's in the inbox. I was assuming we were voting for the isr-sasl2.html in the inbox anyway.

  9. Ge0rG

    I think the general idea is to accept something that looks generally implementable and to finish the spec afterwards?

  10. Kev

    Ah, ok. I thought his latest wasn't in the inbox yet.

  11. Kev

    Ge0rG: As long as it doesn't look harmfully the wrong approach for some reason, I accept generally, yes.

  12. Ge0rG

    So the exact version in the inbox doesn't matter too much?

  13. Kev

    There is an argument to be made for that, yes.

  14. Dave

    Ge0rG, Yes, although ironically I thought I'd implement this afternoon and found I can't because he's tied it into the SASL mechanism, which I hadn't really appreciated.

  15. Ge0rG

    Dave: I'd really love to scale back the SASL thing and just let ISR be an additional token that immediately gives you your old 0198 session

  16. Dave

    Ge0rG, Why? The immediacy can be achieved simply enough without tying it into a SASL mechanism, and gives us flexibility over authentication.

  17. Kev

    And I'm interested in using 'instant re-auth with this key' without involving 198, FWIW.

  18. Kev

    Because I think fast resync is a worthwhile problem to solve, without 198.

  19. Dave

    Kev, CLIENT-KEY can do that, longer-term. But it does mandate an atomic counter at both ends, which might be painful in a cluster.

  20. Dave

    Kev, Flow's HT-* mechanism family should manage it, but it's tied into 198 quite heavily.

  21. Ge0rG

    Kev: I'd say that a instant re-auth that's tied to a short-lived 0198 after-session is technically not a new authentication, as opposed to something like CLIENT-KEY

  22. Dave

    Ge0rG, Well, you connect, do *magic* and then the server knows who you are.

  23. Dave

    Ge0rG, Which makes me suspect that *magic* includes an authentication.

  24. Ge0rG

    Dave: so I have a TCP session with TLS on top of it that I didn't send any data over for half an hour, and then I send another packet, and the other side knows it's from me - is that authentication as well?

  25. Ge0rG

    How often do I need to enter an OTP code?

  26. Zash

    With every TCP segment!

  27. Ge0rG

    Zash: TCP is a stream of bytes. So I think you mean with every byte.

  28. Ge0rG

    But then again, there is TLS overhead.

  29. Zash

    TLS uses blocks somewhat larger than single bytes IIRC

  30. Ge0rG

    Now you made me wonder how TLS operates. Does it fill up its data up to the MSS? Is it playing weird games with Nagle?

  31. Ge0rG

    Do I really want to know?

  32. Zash

    You probably don't want to know.

  33. Ge0rG

    So back to my original question. When does it stop to be the continuation of an ongoing authenticated session and begins to be a new authentication?

  34. Ge0rG

    Does it need to run in the same TLS session? Same TCP session? Same pair of entities? What if I export the TLS state from one entity to another?

  35. Zash

    There's some framing, padding to the cipher block size and a MAC.

  36. Ge0rG

    Zash: that totally doesn't answer my question.

  37. Zash

    I was just telling you what you don't wanna know.