XMPP Council - 2018-01-09

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

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

Dave: there is the Avatar conversion

Dave, three, what daniel said

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

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.

Looks like Daniel, Kev and I all voted for.

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.

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

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

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

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

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

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.

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

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

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

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

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.

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

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

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

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

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?

How often do I need to enter an OTP code?

With every TCP segment!

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

But then again, there is TLS overhead.

TLS uses blocks somewhat larger than single bytes IIRC

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?

Do I really want to know?

You probably don't want to know.

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?

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?

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

Zash: that totally doesn't answer my question.

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