I'm having this discussion on E2E encryption with michael on Twitter, but what he describes about key exchange sounds like a bug. https://twitter.com/mickael/status/1093128804728557570
ralphm
mickael
Tobiashas joined
ralphm
This isn't inherent to the protocol, is it?
lskdjfhas joined
jonas’
does it use multi-item PEP?
dwd
No, the key exchange stuff is pretty rubbish.
Zash
PEP and MAM on login adds a bit, not sure how significant it is
Tobiashas joined
Tobiashas left
dwd
This isn't helped by the key service really needing more smarts than just a big PEP blob anyway.
Zash
Multi-item was less commonly supported by servers before, so would have been a pain to deploy if it was required
Tobiashas left
ralphm
dwd: but is it as bad as mickael describes?
Tobiashas left
Tobiashas left
pep.
ralphm, bundles are only needed on session init
rtq3has left
pep.
So they get fetched at that time
pep.
But session init doesn't happen often
rtq3has joined
Danielhas joined
dwd
ralphm, Well, I don't know about how loaded blatting out a big blob actually makes a server.
ralphm
pep.: Yeah, that was my thought, too.
jonas’
I think the increased message size in MAM is probably more worrisome
pep.
Well that's an issue with e2ee at all right?
jonas’
that affects bandwidths (memory, disk and network) and disk storage
jonas’
pep., yes, that’s kind of the point
ralphm
jonas’: well, I am not surprised about encrypted stuff being bigger in general
pep.
k
Kev
Depends if it's hitting disk for PEP each time or something, I imagine.
Zash
The real problem is that everything is hitting the disk for way more stanzas now than in the past
dwd
Kev, And if not, the memory pressure is probably greatly increased.
Kev
dwd: Quite.
ralphm
But this isn't a property of which protocol we use for e2e, is it?
Kev
Message size? No. Key exchange details? Yes.
ralphm
The increase in MAM storage, I mean.
Kev
(Or ln -s No Not\ Entirely)
ralphm
Right, if the key exchange is suboptimal, then that's a thing we can look into. I'm surprised that mickael says the impact would be 'huge'.
dwd
ralphm, Yes, it can be. MLS, for instance, would be hugely more efficient in bandwidth terms where OMEMO is used within MUCs, for example.
dwd
ralphm, But I would personally just treat OMEMO as the experiment it is, and await MLS patiently, and do things properly then.
ralphm
I don't think we are talking about group chats at this point, though.
pep.
If you don't have to reencrypt for each device, certainly yes :)
goffi
dwd: I forgot to ask you about that by the way, is there any progress and where can we follow them?
pep.
ralphm, for 1:1 you still encrypt for each of your recipient's devices
goffi
(mls)
pep.
With OMEMO
dwd
goffi, MLS has an IETF working group, and is taking time - lots of effort in the low-level crypto.
ralphm
pep.: sure, but what's this about 100s of PreKeys?
dwd
ralphm, That's a property of most of these algorithms, including MLS. Each device must upload a bunch of prekeys, and a new session takes one.
pep.
I'm not exactly sure about prekeys, maybe Syndace can chime in, and why we need 100. I guess that's when people want to start a session with you, and how often you need to renew them
pep.
(renew them > the prekeys)
Zash
What happens if two sessions are started using the same prekey?
dwd
ralphm, My sketch of a XEP for MLS, for instance, says that servers provide a keying service and hand out a single prekey for each device on demand.
Kev
Although even 'having 100 prekeys' doesn't necessitate our current mechanism.
Kev
Right, that'd do it.
dwd
Zash, Nothing - in principle. But it makes the cryptanalysis much harder.
pep.
Zash, that happens regularly, because we don't have reliable message delivery. So some clients will use the same prekey until they get an ACK from the other side
ralphm
(for reference, the WG is here: https://datatracker.ietf.org/wg/mls/)
dwd
ralphm, Thanks.
dwd
ralphm, Note that for each session, the requester will grab all the prekeys, pick a set (one from each device), and then use them. On successful session start, the called device then removes the set from the prekey blob and re-uploads. This new bundle is then pulled by each device.
Daniel
> ralphm, My sketch of a XEP for MLS, for instance, says that servers provide a keying service and hand out a single prekey for each device on demand.
This is probably the 'proper' solution. For omemo we deliberately decided against an omemo component in favor of faster adoption. But learning about the limitations of PEP and how fast we can role out components if we need to (http upload) this is one of the regrettable features of omemo.
Daniel
Or not that much regrettable but rather 'lessons learned'
dwd
Daniel, For sure - and I would note that this is a fine design if treated as an experiment.
Yagizahas joined
ralphm
dwd: sure, but how often does one have a new session? That's still not a common thing, is it?
dwd
ralphm, Every new conversation.
pep.
dwd, really?
pep.
Is it some security thing I don't understand, or is it a limitation, or?
Zash
pep.: What thing?
pep.
what what
dwd
pep., I would think so. The ratcheting means you can re-use a session for lengthy periods, but you'd need to store a fair chunk of cryptographically-sensitive state, so I'd think you'd discard that after a period of inactivity in a conversation and start anew later.
Ge0rGhas joined
ralphm
Daniel: when do sessions expire in Conversations?
dwd
pep., That said, I've not looked at what OMEMO implementations actually do. The spec more or less says "use libsignal", so it's hard to tell.
pep.
I would assume in OMEMO session initiation is not something that happens often, judging by how easy it is to lose messages when negociating a new one. If the other side starts a new session and drops the old one, and I don't, I'll send a message and they won't be able to read it.
Zash
pep.: Cryptosystems usually need something like a 3-way handshake. As I understand it, prekeys are the first step in that. (Is that the "what"?)
Daniel
ralphm: they don't
ralphm
Daniel: so in Conversations, a session between two users doesn't change keys, until you add/remove devices, or explicitly want to use a new key?
Daniel
A session is something that exists between devices. So adding a new device will create an additional session and not change something about the existing ones
Daniel
But the ratchet for each session is of course moved forward on every received message
ralphm
right, I'm trying to understand what the actual traffic behaviour is, with respect to our current key exchange, and whether this is worse in some implementations than others
Syndace
Ugh not reading for a day and 500 messages with a lot about OMEMO >.<
Daniel
ralphm: regarding the Twitter?
ralphm
yeah
Zash
Syndace: Enjoy your FOMO :)
pep.
Syndace, stop slacking off!
Daniel
This is I assume about the prekeys
ralphm
I Slack off all the time, I call it market research, or work, depending who's asking.
Seve
Haha
pep.
:D
Daniel
So on login due to broken pep a client doesn't know if the prekey list on the server is up to date and will update it
Daniel
Which as I just mentioned on Twitter is something one could probably fix now that pep isn't broken
ralphm
so without session resumption (XMPP session, not OMEMO), this might be often
Daniel
That often
Daniel
ralphm: yes
labdsfhas joined
lumihas joined
j.rhas left
j.rhas joined
mimi89999has joined
ThibGhas left
ThibGhas joined
Andrew Nenakhovhas left
architekthas joined
goffihas joined
MattJhas joined
Andrew Nenakhovhas left
lhas joined
mimi89999has joined
Yagizahas joined
goffihas joined
rtq3has left
rtq3has joined
Andrew Nenakhovhas left
mimi89999has joined
grumpyhas joined
grumpyhas joined
karoshihas joined
goffihas joined
rtq3has joined
architekthas joined
lhas joined
Ge0rG
I wonder why people insist on PFS, deniability and per-device keys. If you just have a per-account key that is shared between your devices, you can have such a simple e2ee scheme.
Zash
Ge0rG: Because PFS has more marketing behind it and looks better for ültraparanoid cryptonerds :)
moparisthebest
then why wasn't xep-27 widely adopted/used ?
Zash
OpenPGP is Hard and '27 is awkward
moparisthebest
it's just a different use-case, PFS has valuable properties, it also has downsides
Zash
It's got the word "Perfect" in it!!!1
Ge0rG
*cough* https://op-co.de/tmp/SEX.html *cough*
Zash
moparisthebest: Also beacuse crypto wasn't hip and cool and buzzword-compatible enough back then
moparisthebest
plus it doesn't have signing or replay prevention
Zash
Snowden and Facebook scandals does a lot of marketing for magic crypto dust and these last years seem to have been a good time to push this stuff
Zash
moparisthebest: As I said, '27 is awkward.
dwd
moparisthebest, eSessions ticked most boxes, but wasn't ever deployed either.
Zash
Gajim had it (removed now?)
dwd
moparisthebest, But also, there's RFC 3923, of course.
dwd
Zash, Yes, indeed. MattJ and I used to fiddle constantly to stop it encrypting as I recall.
dwdnotes that even RFC 3923 had full-stanza encryption.
lorddavidiiihas left
moparisthebesthas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas joined
Ge0rG
It looks like xmpp.org is flapping ipv6 again.
Ge0rG
IPv4 is also affected.
Ge0rG
Sometimes it works, sometimes it fails.
404.cityhas left
Danielhas left
jmpmanhas joined
jonas’
my monitoring agrees
Ge0rG
But now also my IRCnet fails, so maybe it's a larger issue somewhere in Yurop
Ge0rGhas left
edhelas
the Brexit has strarted
jonas’
bad network weather
Zash
Dun dun duuuun
debaclehas joined
j.rhas joined
j.rhas joined
j.rhas joined
lumihas left
dwd
Council meeting about to start over there: --> council@muc.xmpp.org
jonas’
/correct Council meeting about to start over there: --> xmpp:council@muc.xmpp.org?join
Zash
/sudo -u dwd /correct ...
jonas’
I can haz sudo XEP?
Zash
SASL sorta has it already actually
jonas’
yeah, without reconnecting pls
Zash
authz vs authn something something
Zash
But yeah, overwriting other peoples messages ... might have its uses
Zash
Tho attaching or somesuch might be fine for most of them
lskdjfhas left
Nekithas left
Nekithas joined
lumihas joined
Danielhas joined
peterhas joined
neshtaxmpphas left
neshtaxmpphas left
Danielhas left
Danielhas joined
goffihas joined
!xsf_Martinhas joined
matlaghas left
waqashas joined
lskdjfhas joined
Andrew Nenakhovhas joined
lovetoxhas joined
Nekithas left
debaclehas left
Marandahas joined
Nekithas joined
Danielhas left
Danielhas joined
goffihas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
jmpmanhas joined
Danielhas left
Danielhas joined
lorddavidiiihas joined
goffihas joined
Guushas joined
tahas joined
Danielhas left
Danielhas joined
rionhas left
rionhas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
jjrhhas left
jjrhhas joined
valohas left
valohas joined
valohas left
jjrhhas left
jjrhhas joined
Danielhas left
Danielhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
alameyohas joined
Andrew Nenakhovhas left
Steve Killehas left
Steve Killehas left
pep.has joined
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
valohas joined
Steve Killehas joined
rtq3has joined
valohas left
Andrew Nenakhovhas joined
tuxhas joined
wurstsalathas joined
Marandahas joined
Marandahas joined
MattJhas left
marc_has joined
Alexhas joined
Tobiashas joined
intosihas left
intosihas joined
valohas joined
labdsfhas joined
rtq3has left
rtq3has joined
rtq3has left
rtq3has joined
debaclehas joined
valohas left
Tobiashas joined
404.cityhas joined
equilhas joined
valohas joined
Guushas left
rtq3has left
rtq3has joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
j.rhas joined
j.rhas joined
ThibGhas left
ThibGhas joined
Marandahas joined
Zashhas left
lskdjfhas joined
grumpyhas joined
Guushas joined
debaclehas left
mimi89999has left
APachhas left
APachhas joined
labdsfhas left
labdsfhas joined
igoosehas left
rtq3has left
rtq3has joined
Andrew Nenakhovhas left
rionhas joined
rionhas joined
Andrew Nenakhovhas joined
APachhas left
APachhas joined
sezuanhas joined
sezuanhas joined
moparisthebesthas joined
efrithas joined
dwdhas left
rionhas joined
rionhas left
rionhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
labdsfhas left
mimi89999has joined
frainzhas left
frainzhas joined
!xsf_Martinhas joined
thorstenhas left
labdsfhas joined
flow
So fun question, is the 'by' attribute of stanza errors (RFC 6120 § 8.3.2) guaranteed to be an JID, or can it be an arbitrary string?
flow
I am missing the "the JID of" before "the entity" in the paragraph specifying it, just like it is done everywhere else
sezuanhas joined
sezuanhas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
thorstenhas joined
Zash
flow: Is there any text that suggests that "entity" is equivalent to JID?
flow
Zash, yes and no, guess it depends on the type of the entity
Ge0rG
flow: you don't want to enforce this in the type system, do you?
Zash
I thought it was a JID
Ge0rG
I'm really excited to get my client crashed by type system exceptions caused by remote entities!
igoosehas joined
Zash
Maybe(JID | String)
Zash
Have fun
Ge0rG
Someone is going to mess up my bookmarks with a robot face MUC and I'll end up in an endless connect loop.
Link Mauvehas joined
Zashhas left
ThibGhas left
ThibGhas joined
lorddavidiiihas left
labdsfhas left
labdsfhas joined
equilhas left
equilhas joined
lorddavidiiihas joined
Alexhas left
peterhas left
lnjhas left
lnjhas left
lnjhas joined
lnjhas left
lnjhas left
lnjhas joined
Guushas left
Guushas joined
architekthas joined
Guushas left
frainzhas left
frainzhas joined
architekthas left
rtq3has left
rtq3has joined
nycohas left
goffihas joined
Guushas joined
lnjhas left
lnjhas left
lnjhas joined
404.cityhas left
Link Mauvehas left
peterhas joined
Guushas left
Guushas joined
architekthas joined
waqashas left
tuxhas joined
Danielhas left
Danielhas joined
rion
It seems there is an error in https://xmpp.org/extensions/xep-0261.html examples 9, 10. New SID has to be different for second stream but it has to be the same for for <transport> and <open>
Danielhas left
Danielhas joined
lorddavidiiihas left
Nekithas joined
MattJ
rion, can you post that to the standards@ list?
rion
I'll send a pull request with fix
remkohas left
Danielhas left
Danielhas joined
Link Mauvehas joined
Danielhas left
Danielhas joined
grumpyhas left
lovetox
rion, do you mean example 10 has the wrong sid
Guushas left
Guushas joined
rion
lovetox: yes
grumpyhas joined
lovetox
should be bt8a71h6 instead
j.rhas left
lovetox
yeah seems like a copy/paste error
j.rhas joined
rion
https://github.com/xsf/xeps/pull/755
Danielhas left
Danielhas joined
j.rhas joined
Guushas left
olihas joined
j.rhas left
j.rhas joined
Danielhas left
Danielhas joined
j.rhas left
j.rhas joined
j.rhas left
j.rhas joined
Tobiashas joined
Link Mauve
Daniel, could you add IPv6 support to conference.siacs.eu please?
architekthas joined
Link Mauve
I don’t currently have an IPv4 on my server, and it prevents me from joining.
Daniel
Link Mauve: it's on the todo list
Link Mauve
Great, thanks. :)
Link Mauve
Kev, could you do the same with rooms.swift.im please?
j.rhas joined
Zashhas left
j.rhas left
j.rhas joined
Guushas joined
sezuanhas left
lumihas left
lovetoxhas left
rion
another error https://xmpp.org/extensions/xep-0167.html example 50. wrong action.
pep.
rion, please PR :)
moparisthebesthas joined
rion
https://github.com/xsf/xeps/pull/756
pep.
thanks o/
pep.has joined
neshtaxmpphas joined
neshtaxmpphas joined
vaulorhas left
rion
xep-0167 example 48 probably should include some candidates to <transport> or at least refer to consequent transport-info actions for transport negotiation.