-
moparisthebest
dwd: good article
-
moparisthebest
And on that topic, it's about time, does anyone know if anyone has started XMPP over QUIC work yet?
-
moparisthebest
It handles switching networks itself, so in theory we wouldn't even need stream management anymore
-
waqas
dwd: Is the image under "High Latency" intended to be a gif of a spinning circle?
-
Arc
why QUIC instead of SCTP?
-
Zash
Arc: New hotness?
-
dwd
Waqas, must be slow loading.
-
dwd
Arc, QUIC has lower start-up cost, I think, plus it's likely to be around in implementations because of Google pushing it.
-
flow
dwd, the xep368 link is broken
-
flow
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.
-
Zash
dwd, "latencies still have a visible human effect even when they drop below 30ms" - isn't that the other way around?
-
Zash
dwd, and browsers supposedly don't do pipelining
-
dwd
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.
-
ralphm
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.
-
flow
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
-
ralphm
Yeah, that's an excellent, but bit dated, document.
-
ralphm
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.
-
Zash
The "resource" ?
-
ralphm
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).
-
ralphm
Zash: the Connection ID: https://tools.ietf.org/html/draft-ietf-quic-transport-24#section-5
-
dwd
That scenario is what we see, but on a constant basis as doctors and nurses walk between wards.
-
Zash
Moar access points!
-
flow
ralphm, Isn't quick designed to survive roaming between different networks?
-
flow
ahh you "like the part", I read "like to have"…
-
flow
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?
-
Guus
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?
-
flow
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?
-
Guus
(14 January is in one week from now)
-
flow
Guus, as I am just back from vacation I was about to write a mail regarding that
-
Guus
👍
-
Guus
just wanted to stir things. I'll await your email 🙂
-
flow
Guus, btw, 14th is not the deadline if I am not mistaken
-
Guus
flow you're right
-
Guus
that's when registration opens.
-
Guus
sorry for that.
-
Guus
> All organizations wishing to be a part of GSoC 2020 must complete their application by February 5, 2020 20:00
-
Guus
Sorry for butting in the conversation then
-
flow
na, no worries
-
ralphm
dwd: maybe we should make some time around the summit to work on this?
-
dwd
Flow, sm is deployed over websockets by Stanza, Prosody, Openfire, and probably others.
-
flow
dwd, so I could resume a session previously connected via TCP over webscokets on Openfire and Prosody?
-
Ge0rG
Speaking of SM over websockets, we still miss a way to sm-resume an anonymous session
-
Zash
Did ISR allow that?
-
dwd
Flow, ... Maybe?
-
dwd
Zash, yes, isr would allow that.
-
dwd
I think.
-
Zash
flow, yes, except for the part where Prosody doesn't officially support 198 out of the box
-
flow
So SM with TCP and Websockets ✓ what about SM resumption over BOSH and QUIC?
-
flow
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?
-
flow
Compared to that, SM over QUIC appears straight forward
-
dwd
I think lots of networks will block QUIC, so SM is still useful.
-
flow
Probably even if QUIC is available nearly everhwere, SM resumption across transports is still nice to have
-
Ge0rG
I agree with that, and resuming 0198 from a gone TCP connection on a BOSH, because you moved into nazi firewall land, seems sensible
-
ralphm
dwd: why would they block QUIC?
-
dwd
ralphm, Some of the hospitals we work in block everything and whitelist a handful of IP addresses and ports.
-
dwd
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".
-
ralphm
Also note that there's been an effort to allow QUIC to multiplex with STUN and TURN.
-
ralphm
So indeed, if you are in a network that also blocks WebRTC, then you'd be out of luck.
-
ralphm
dwd: would you count medical institutions in such lands?
-
dwd
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.
-
ralphm
Right
-
larma
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)
-
pep.
dwd, "the malware attack", you mean the ransomware?
-
jonas’
https://sha-mbles.github.io/ via pep.
-
ralphm
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.
-
ralphm
And dwd has discussed energy usage in his XEP a long time ago already.
-
ralphm
I.e. his argument there is that radio usage affects battery a great deal more.
-
ralphm
(larma)
-
dwd
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.
-
dwd
SO it'll make a difference, though whether this becomes significant or not I can't tell. My gut feeling is probably not.
-
larma
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
-
larma
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
-
dwd
[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.
-
dwd
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.
-
dwd
Still, by all means measure it.
-
larma
Maybe we should just try it out, I am at least rather certain that it won't hurt ;)
-
dwd
Well, aside from fixing schemas, etc.
-
larma
dwd: but using schema is optional for EXI, no?
-
dwd
Sort of. My (poor) understanding was that using EXI without strict schemas was a bit pointless.
-
Kev
Isn't it ~=deflate at that point?
-
dwd
Well, only if you're using deflate.
-
dwd
And if you're using deflate, then you have a compression oracle, so...
-
dwd
You're also probably outweighing any benefit, CPU-wise.
-
larma
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)
-
ralphm
Arc has done a lot of work on EXI, so you may want to ask him.
-
larma
I talked with him a few months ago, so most of my EXI knowledge is actually from him ;)
-
dwd
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.
-
Zash
Was there a mode that's equivalent to sending generic XML packed in C-like structs?
-
dwd
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.
-
moparisthebest
Arc, simple, because only QUIC, not SCTP, has been blessed by "the browsers", so only it has a chance to work into the future :'(
-
flow
"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?
-
Ge0rG
What would be wrong with the client informing the server on its schema on session setup?
-
pep.
moparisthebest, and by "the browsers" you mean google? :)
-
Ge0rG
Google Chrome and Google Firefox.
-
moparisthebest
well I meant chrome and firefox but yea that's a different thing to cry about
-
pep.
Oh and Google Brave! The privacy-minded browser that's chained to a block
-
ralphm
moparisthebest, I think what I wrote above as the reason is a lot more plausible.
-
dwd
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.
-
dwd
ANd the startup cost is roughly the same as TCP, unlike QUIC.
-
moparisthebest
also no encryption built in with SCTP, is there even encryption defined to go over it?
-
Zash
IPsec?
-
Zash
How's mptcp these days ?
-
moparisthebest
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
-
Zash
MPTCP was supposed to be compatible with TCP
-
larma
SCTP over dTLS over UDP?
- larma feels like reconstructing the WebRTC stack 😀
-
moparisthebest
so I guess that was a "no" to my original question "has anyone started specifying XMPP-over-QUIC" ?
-
moparisthebest
the hardest part will be defining how to pronounce XoQ
-
ralphm
AFAIK, nobody has done this yet, and I nudged dwd with a suggestion to work on it with him around the Summit.
-
Ge0rG
What kind of standardization is needed for that?
-
ralphm
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.
-
ralphm
For comparison, look at https://tools.ietf.org/html/rfc7395 that was done for the WebSocket binding.
-
ralphm
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.
-
dwd
FWIW, I don't think this is a Summit task.
-
ralphm
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.
-
Ge0rG
does that actually require a high-bandwidth connection?
-
dwd
Ge0rG, Only until we have QUIC.
-
Ge0rG
Are we speaking of the same kind of connection?
-
moparisthebest
here is an example of another protocol over QUIC https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-07
-
moparisthebest
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
-
jonas’
where’s the example which abolishes quic?
-
moparisthebest
at this point I'd probably just lean towards "indistinguishable from HTTP" to head off problems down the road
-
moparisthebest
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
-
Zash
I don't wanna live in a world where everyhing is HTTP
-
moparisthebest
There are no Websockets over http/2, I'm pretty sure there ane no Websockets over http/3 either
-
moparisthebest
I don't think any of us want to live in that world Zash , yet here we are :(
-
edhelas
can't wait for QUIC over XMPP
-
MattJ
over pubsub you mean?
-
edhelas
let's wait for full Pubsub support in the XMPP servers first
-
dwd
moparisthebest, HTTP/2 doesn't have websockets?
-
moparisthebest
nope
-
Zash
Doesn't ALPN remove the need somewhat? Like, why talk something over ws when you can talk something directly?
-
jonas’
browsers still don’t allow you to open arbitrary sockets, do they?
-
Zash
Of course not
-
moparisthebest
1. you are running in a web browser 2. you want to pretend to be a web browser because evil middleboxen
-
Zash
1. I'm not. 2. I don't.
-
dwd
moparisthebest, RFC 8441 BTW
-
moparisthebest
dwd, ah awesome, that's newer, I *suppose* that might *just work* over http/3 too
-
jonas’
if we accept that the world is going to be *-over-HTTP anyways, why keep bothering with XMPP?
-
Zash
give up and join matrix?
-
jonas’
would make much more sense to drop that layer of complexity and do something with JSON-over-HTTP directly.
-
moparisthebest
HTTP doesn't solve the problems that XMPP does?
-
jonas’
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
-
jonas’
easier = with less technology stacked on top of each other
-
moparisthebest
JSON vs XML is a different discussion, JSON isn't any more closely tied to HTTP than XML is it?
-
pep.
it isn't. it also isn't more closely tied to browsers than XML is
-
jonas’
also not the main point I’m trying to make
-
jonas’
JSON vs. XML does indeed not matter
-
jonas’
question is why bother with XMPP if we’re going to squash it over HTTP either way?
-
moparisthebest
I'm not sure I buy your argument yet, that you can do it easier with plain HTTP than XMPP over HTTP
-
jonas’
for certain definitions of plain HTTP
-
moparisthebest
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)
-
moparisthebest
sorry, http/3 is http/2 over QUIC
-
jonas’
did I mention that’s all awful?
-
Zash
everything is terrible
-
jonas’
I’m going to start make dinner before this ruins my night
-
moparisthebest
*all* of it's awful?
-
moparisthebest
at least QUIC replacing TCP+TLS doesn't seem bad to me
-
dwd
Seems fine to me too.
-
Zash
Something something potato farming
-
pep.
Zash, so you can throw potatoes at Google?
-
moparisthebest
it has plenty of other upsides, but maybe the best for everyone is connections surviving network/ip switches
-
Zash
pep., strategic ballistic potato warfare?
-
jonas’
see, QUIC isn’t even an RFC yet
-
moparisthebest
it's pretty close, and widely implemented/deployed :)
-
jonas’
and that everyone is talking about building stuff on it is plain running behind google and chromium to not fall perceivedly behind
-
jonas’
widely ipmlemented/deployed and not through IETF process is a red flag to me
-
moparisthebest
some significant percentage of XMPP isn't an RFC either
-
jonas’
especially if driven by a large commercial entity
-
moparisthebest
it is through an IETF process
-
jonas’
"through" as in "passed completely"
-
Zash
Simliar to HTTP/2?
-
dwd
The concern is mostly whether, if Chrome and the IETF diverge, will the IETF's draft get "correctd" or the Chrome implementation.
-
moparisthebest
jonas’, no I'm not talking about the old/dead google/quic, but the widely implemented/deployed ietf/quic
-
jonas’
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.
-
jonas’
moparisthebest, ietf/quic, as per the expired draft?
-
jonas’
a draft which has expired for two and a half years now
-
jonas’
anyways, dinner
-
Zash
Which draft?
-
moparisthebest
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
-
Zash
https://tools.ietf.org/wg/quic/ most of those look fairly recent
-
dwd
Ah, I think jonas’ was looking at draft-tsvwg-quic-protocol, which died (and was shelved, IIRC, until HTTP/2 was done).
-
Zash
But HTTP is frozen in time!!!!1!!
-
!XSF_Martin
That's a good album.
- !XSF_Martin starts humming the 'redneck stomp'
-
moparisthebest
not good https://sha-mbles.github.io/
-
!XSF_Martin
Sha1 is used for scram in prosody, right?
-
MattJ
In XMPP
-
dwd
SHA-1 is used in SCRAM-SHA-1, yes.
-
dwd
Time to bump the MTI again...
-
Zash
SHA-1 broken doesn't mean that HMAC-SHA-1 is broken
-
!XSF_Martin
Is it possible to upgrade to something not yet broken?
-
Zash
Nor that PBKDF2 is broken
-
!XSF_Martin
> SHA-1 broken doesn't mean that HMAC-SHA-1 is broken So scram-sha-1 is not affected?
-
Zash
!XSF_Martin: Not easily
-
dwd
https://twitter.com/matthew_d_green/status/1214585587874877440
-
jonas’
it isn’t, because SCRAM doesn’t care much about collision resistance. also, love the analogy of Matthew Green there
-
dwd
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")
-
Zash
Practically it's nontrivial to upgrade
-
dwd
It'd be nice if we had a forced password update protocol.
- dwd looks meaningfully at XEP-0388
-
!XSF_Martin
> Practically it's nontrivial to upgrade That's better than impossible. 🙂
-
MattJ
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
-
Zash
MattJ: No, they will refuse
-
MattJ
Because it's 2020 now and software is secure?
-
MattJ
Did I miss this?
-
Zash
Conversations does this
-
MattJ
Any others?
-
Zash
Dunno
-
MattJ
Conversations can be fixed (to do something sensible)
-
Zash
Allowing downgrade attacks ?
-
MattJ
Which would be SASL2 of course
-
Zash
Right
-
moparisthebest
I wonder what it means for git/hg
-
Zash
They already started looking at replacing sha1
-
jonas’
I think they need to hurry up
-
moparisthebest
> 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
-
moparisthebest
so "it's probably ok for now" but not rock solid
-
!XSF_Martin
A sealife habitat?
-
dwd
MattJ, Quite a few spot if you remove SCRAM-SHA-1 suddenly.
-
dwd
MattJ, But yeah, SASL2 and a password reset task would be awesome. Except clients would still try to use SCRAM-SHA-1.
-
Ge0rG
there is still PLAIN. But you can't downgrade secure clients.
-
moparisthebest
if PLAIN is always good enough for HTTP...
- moparisthebest ducks and runs
-
dwd
Goodness no. The web world uses bearer tokens, which are entirely different.
-
Ge0rG
Say what? Authorization basic can't hear you