XSF Discussion - 2020-01-07

dwd: good article

And on that topic, it's about time, does anyone know if anyone has started XMPP over QUIC work yet?

It handles switching networks itself, so in theory we wouldn't even need stream management anymore

dwd: Is the image under "High Latency" intended to be a gif of a spinning circle?

why QUIC instead of SCTP?

Arc: New hotness?

Waqas, must be slow loading.

Arc, QUIC has lower start-up cost, I think, plus it's likely to be around in implementations because of Google pushing it.

dwd, the xep368 link is broken

moparisthebest, I'd expect that XMPP over QUIC is not that hard to specifiy, it is probalby even esier than XMPP over TCP+TLS, because QUIC does most of the work for you.

dwd, "latencies still have a visible human effect even when they drop below 30ms" - isn't that the other way around?

dwd, and browsers supposedly don't do pipelining

No, latencies still have an effect that low. Usually because of cumulative interaction, like sequential rtts, but in highly interactive stuff, I think people can still tell there's a lag just on a single rtt.

Arc: primarily because SCTP has been tried before, and stranded on the fact that there is major inertia in middleboxes. They won't support new transport layer supports, and I think that this is the primary reason for Google to start work on QUIC.

what ralphm said, and just when I asked myself about the differences and similarities between QUIC and SCTP, I found https://tools.ietf.org/html/draft-joseph-quic-comparison-quic-sctp-00

Yeah, that's an excellent, but bit dated, document.

I have been talking on and off with people about the prospects of XMPP-over-QUIC. Besides having TLS 1.3 built in, and the advantages of fewer round-trips upon reconnection (we probably still need to do work ourselves here, too), I also like the part where you have an identifier for a connection that survives roaming between different networks.

The "resource" ?

E.g. when in an office on a higher floor going out for lunch, you'll be going WiFi - Cellular (elevator) - Wifi (lower floor) - Cellular (elevator) - WiFi (lobby) - Cellular (outside).

Zash: the Connection ID: https://tools.ietf.org/html/draft-ietf-quic-transport-24#section-5

That scenario is what we see, but on a constant basis as doctors and nurses walk between wards.

Moar access points!

ralphm, Isn't quick designed to survive roaming between different networks?

ahh you "like the part", I read "like to have"…

slightly related: As I am working on Smack's lower layers, is there any reason I shouldn't prepare Smack to perform SM resumption over different transports besides TCP?

PSA: January 14, 2020 is the deadline for organisations to submit to GSoC. Now that I see some of the usual suspects here, I thought I'd bring that up. flow if we'd choose to apply, would you consider running as org admin again?

Even though xep198 was probably written with SM resumption only being performed over TCP transports in mind, is there any reason we shouldn't allow SM resumption over different transports?

(14 January is in one week from now)

Guus, as I am just back from vacation I was about to write a mail regarding that

👍

just wanted to stir things. I'll await your email 🙂

Guus, btw, 14th is not the deadline if I am not mistaken

flow you're right

that's when registration opens.

sorry for that.

> All organizations wishing to be a part of GSoC 2020 must complete their application by February 5, 2020 20:00

Sorry for butting in the conversation then

na, no worries

dwd: maybe we should make some time around the summit to work on this?

Flow, sm is deployed over websockets by Stanza, Prosody, Openfire, and probably others.

dwd, so I could resume a session previously connected via TCP over webscokets on Openfire and Prosody?

Speaking of SM over websockets, we still miss a way to sm-resume an anonymous session

Did ISR allow that?

Flow, ... Maybe?

Zash, yes, isr would allow that.

I think.

flow, yes, except for the part where Prosody doesn't officially support 198 out of the box

So SM with TCP and Websockets ✓ what about SM resumption over BOSH and QUIC?

I can see that we may not want to put in effort to think about SM over BOSH, as it would potentially duplicate a lot of what BOSH already does, or maybe there is a chance to unify it? But how relevant is BOSH given that we have Websockets now?

Compared to that, SM over QUIC appears straight forward

I think lots of networks will block QUIC, so SM is still useful.

Probably even if QUIC is available nearly everhwere, SM resumption across transports is still nice to have

I agree with that, and resuming 0198 from a gone TCP connection on a BOSH, because you moved into nazi firewall land, seems sensible

dwd: why would they block QUIC?

ralphm, Some of the hospitals we work in block everything and whitelist a handful of IP addresses and ports.

ralphm, QUIC operates over UDP, right? So I'd imagine there's little hope it'll just work in any kind of "nazi firewall land".

Also note that there's been an effort to allow QUIC to multiplex with STUN and TURN.

So indeed, if you are in a network that also blocks WebRTC, then you'd be out of luck.

dwd: would you count medical institutions in such lands?

Some of them certainly are. There's a lot of well-placed concern about infosec in the NHS, especially after the malware attacks a couple of years back.

Right

dwd, nice blog post. Just to play devil's advocate here, I think your "even on mobile" paragraph is not fair. Optimizing for mobile is not only about bandwidth and latency, it also needs to consider energy consumption (which seems to be something where EXI may have some significant advantage over plaintext XML), constantly switching networks (change in ip addreseses / tcp connections breaking up) and data consumption (due to limited plans). Also throttled mobile networks (after you exceeded your "flatrate"'s high speed data) can go as low as 32 kbit/s (shared with all apps on the phone)

dwd, "the malware attack", you mean the ransomware?

https://sha-mbles.github.io/ via pep.

I'm not sure if data consumption is affected by using using EXI, though. I believe mobile networks charge based on certain minimum packet sizes.

And dwd has discussed energy usage in his XEP a long time ago already.

I.e. his argument there is that radio usage affects battery a great deal more.

(larma)

No, I think larma is right, modulo "significant". Transmitting EXI is lower octets, and while it'll probably cost the same, it'll be less power. Additionally, receiving EXI might come in under radio limits, though I have no idea if my knowledge on FACH etc is useful post-3G.

SO it'll make a difference, though whether this becomes significant or not I can't tell. My gut feeling is probably not.

I think EXI is more important from the save energy perspective than from the save bandwidth/data perspective. Significant might be a bit to much, but at least measurable

It also depends on the type of messages you send around. If it's only messages with a body, then impact is far less than if you include messages like receipts and so on that can profit much more (relatively spoken) from EXI

‎[23:24:25] ‎dwd‎: True, if you were shipping complex and large xml around like atom, it might make a difference. But EXI is most useful for reducing processor and memory load, not bandwidth.

But I don't think that's going to be very significant at all for a mobile handset - there I was meaning in terms of IoT and embedded devices.

Still, by all means measure it.

Maybe we should just try it out, I am at least rather certain that it won't hurt ;)

Well, aside from fixing schemas, etc.

dwd: but using schema is optional for EXI, no?

Sort of. My (poor) understanding was that using EXI without strict schemas was a bit pointless.

Isn't it ~=deflate at that point?

Well, only if you're using deflate.

And if you're using deflate, then you have a compression oracle, so...

You're also probably outweighing any benefit, CPU-wise.

Wasn't it somehow learning the "schema" (probably rather qnames) from the actual XML being exchanged? Maybe I'm confusing it with something else. Yes that's probably similar to deflate(xml) but minus the xml parsing (because EXI already takes care of that in an efficient way)

Arc has done a lot of work on EXI, so you may want to ask him.

I talked with him a few months ago, so most of my EXI knowledge is actually from him ;)

EXI has two switches - strict schema and deflate. With strict schema both ends will need to agree on the schemas used, and any additional attributes and extra bits in other namespaces (for example) are removed.

Was there a mode that's equivalent to sending generic XML packed in C-like structs?

Zash, That's sort of what EXI does, I believe, though the element tags etc are given identifiers based on the schema most of the time.

Arc, simple, because only QUIC, not SCTP, has been blessed by "the browsers", so only it has a chance to work into the future :'(

"With strict schema both ends will need to agree on the schemas used, and any additional attributes and extra bits in other namespaces (for example) are removed." Wasn't there a, potential configurable, fallback to schema-uninformed mode if the schemas are not available?

What would be wrong with the client informing the server on its schema on session setup?

moparisthebest, and by "the browsers" you mean google? :)

Google Chrome and Google Firefox.

well I meant chrome and firefox but yea that's a different thing to cry about

Oh and Google Brave! The privacy-minded browser that's chained to a block

moparisthebest, I think what I wrote above as the reason is a lot more plausible.

Also not entirely clear what SCTP would buy us here. It does allow multiple endpoints at each end of a VC, but I don't think it'll allow for sudden network switching.

ANd the startup cost is roughly the same as TCP, unlike QUIC.

also no encryption built in with SCTP, is there even encryption defined to go over it?

IPsec?

How's mptcp these days ?

I think it's equally dead for the reason ralphm said, too many middleboxes don't do IP, they only do UDP and TCP, so those are the only protocols allowed to exist in the future

MPTCP was supposed to be compatible with TCP

SCTP over dTLS over UDP?

so I guess that was a "no" to my original question "has anyone started specifying XMPP-over-QUIC" ?

the hardest part will be defining how to pronounce XoQ

AFAIK, nobody has done this yet, and I nudged dwd with a suggestion to work on it with him around the Summit.

What kind of standardization is needed for that?

Well, I think the best approach would be an IETF Draft. A few words on TLS already done at the transport layer, some on session reestablishment. I need to look into it in detail.

For comparison, look at https://tools.ietf.org/html/rfc7395 that was done for the WebSocket binding.

Then, if you want to go fancy, there could be another spec on how you might make use of the connection for multiplexing media streams with Jingle, TURN.

FWIW, I don't think this is a Summit task.

dwd: I don't think it is a Summit task. It is something we could maybe discuss, figure out, whatever, around the Summit, while there's a high bandwidth connection in place.

does that actually require a high-bandwidth connection?

Ge0rG, Only until we have QUIC.

Are we speaking of the same kind of connection?

here is an example of another protocol over QUIC https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-07

but we probably want to consider if we want to take the same approach as https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-07#section-3.5 or whether we should just throw up our hands and define XMPP-over-HTTP/QUIC

where’s the example which abolishes quic?

at this point I'd probably just lean towards "indistinguishable from HTTP" to head off problems down the road

but maybe you don't and if you are faced with such a crap network you do XMPP-over-BOSH-over-HTTP/QUIC and cry in a corner

I don't wanna live in a world where everyhing is HTTP

There are no Websockets over http/2, I'm pretty sure there ane no Websockets over http/3 either

I don't think any of us want to live in that world Zash , yet here we are :(

can't wait for QUIC over XMPP

over pubsub you mean?

let's wait for full Pubsub support in the XMPP servers first

moparisthebest, HTTP/2 doesn't have websockets?

nope

Doesn't ALPN remove the need somewhat? Like, why talk something over ws when you can talk something directly?

browsers still don’t allow you to open arbitrary sockets, do they?

Of course not

1. you are running in a web browser 2. you want to pretend to be a web browser because evil middleboxen

1. I'm not. 2. I don't.

moparisthebest, RFC 8441 BTW

dwd, ah awesome, that's newer, I *suppose* that might *just work* over http/3 too

if we accept that the world is going to be *-over-HTTP anyways, why keep bothering with XMPP?

give up and join matrix?

would make much more sense to drop that layer of complexity and do something with JSON-over-HTTP directly.

HTTP doesn't solve the problems that XMPP does?

sure, but you can solve those problems on top of HTTP obviously, and you can do that easier than by wrapping XMPP in Websockets over HTTP

easier = with less technology stacked on top of each other

JSON vs XML is a different discussion, JSON isn't any more closely tied to HTTP than XML is it?

it isn't. it also isn't more closely tied to browsers than XML is

also not the main point I’m trying to make

JSON vs. XML does indeed not matter

question is why bother with XMPP if we’re going to squash it over HTTP either way?

I'm not sure I buy your argument yet, that you can do it easier with plain HTTP than XMPP over HTTP

for certain definitions of plain HTTP

just to be clear definition-wise, QUIC replaces TCP+TLS, http/3 is HTTP over QUIC, and we could end up doing XMPP over QUIC *and/or* XMPP over http/3 (and the latter could be BOSH, Websockets, or something new)

sorry, http/3 is http/2 over QUIC

did I mention that’s all awful?

everything is terrible

I’m going to start make dinner before this ruins my night

*all* of it's awful?

at least QUIC replacing TCP+TLS doesn't seem bad to me

Seems fine to me too.

Something something potato farming

Zash, so you can throw potatoes at Google?

it has plenty of other upsides, but maybe the best for everyone is connections surviving network/ip switches

pep., strategic ballistic potato warfare?

see, QUIC isn’t even an RFC yet

it's pretty close, and widely implemented/deployed :)

and that everyone is talking about building stuff on it is plain running behind google and chromium to not fall perceivedly behind

widely ipmlemented/deployed and not through IETF process is a red flag to me

some significant percentage of XMPP isn't an RFC either

especially if driven by a large commercial entity

it is through an IETF process

"through" as in "passed completely"

Simliar to HTTP/2?

The concern is mostly whether, if Chrome and the IETF diverge, will the IETF's draft get "correctd" or the Chrome implementation.

jonas’, no I'm not talking about the old/dead google/quic, but the widely implemented/deployed ietf/quic

moparisthebest, the core of XMPP is IETF-realm, and everything on top of that is XSF-realm, which as kind of a fork of some IETF workgroup is okay in my book. it’s an open process with controls to prevent a single company from taking over.

moparisthebest, ietf/quic, as per the expired draft?

a draft which has expired for two and a half years now

anyways, dinner

Which draft?

jonas’, https://quicwg.org/ "QUIC is an IETF Working Group that is chartered to deliver the next transport protocol for the Internet." I don't see what you are worried about exactly

https://tools.ietf.org/wg/quic/ most of those look fairly recent

Ah, I think jonas’ was looking at draft-tsvwg-quic-protocol, which died (and was shelved, IIRC, until HTTP/2 was done).

But HTTP is frozen in time!!!!1!!

That's a good album.

not good https://sha-mbles.github.io/

Sha1 is used for scram in prosody, right?

In XMPP

SHA-1 is used in SCRAM-SHA-1, yes.

Time to bump the MTI again...

SHA-1 broken doesn't mean that HMAC-SHA-1 is broken

Is it possible to upgrade to something not yet broken?

Nor that PBKDF2 is broken

> SHA-1 broken doesn't mean that HMAC-SHA-1 is broken So scram-sha-1 is not affected?

!XSF_Martin: Not easily

https://twitter.com/matthew_d_green/status/1214585587874877440

it isn’t, because SCRAM doesn’t care much about collision resistance. also, love the analogy of Matthew Green there

More particularly, I do not know that HMAC-SHA-1 is safe (whereas I do know that HMAC-MD5 is safe, or rather, as a cryptographer said over coffee, "Yeah, I think that's still safe though you'd be insane to use it of course")

Practically it's nontrivial to upgrade

It'd be nice if we had a forced password update protocol.

> Practically it's nontrivial to upgrade That's better than impossible. 🙂

Zash: other way around. You mean theoretically it's nontrivial to upgrade. Practically speaking, I doubt most clients will blink if you one day just offer PLAIN

MattJ: No, they will refuse

Because it's 2020 now and software is secure?

Did I miss this?

Conversations does this

Any others?

Dunno

Conversations can be fixed (to do something sensible)

Allowing downgrade attacks ?

Which would be SASL2 of course

Right

I wonder what it means for git/hg

They already started looking at replacing sha1

I think they need to hurry up

> linus said attacks like that on git are harder because the hash input is tagged with a type/length, so the collision would have to be the same length

so "it's probably ok for now" but not rock solid

A sealife habitat?

MattJ, Quite a few spot if you remove SCRAM-SHA-1 suddenly.

MattJ, But yeah, SASL2 and a password reset task would be awesome. Except clients would still try to use SCRAM-SHA-1.

there is still PLAIN. But you can't downgrade secure clients.

if PLAIN is always good enough for HTTP...

Goodness no. The web world uses bearer tokens, which are entirely different.

Say what? Authorization basic can't hear you