XSF Discussion - 2014-03-01

Kev, WHile I remember, you had objections to my XEP-0001 pass; could you post them to the list so others can agree/disagree?

Yes. It's in my todo system. This isn't particularly time-critical though, is it?

Kev, I think that the correct thing is that Editor approves Humour, but will run things past COuncil members and other advisors individually to ensure sanity. Possibly mandate that it's never me, since it hasn't ever been as far as I know. :-)

I'd like to keep momentum up on the discussion, if possible, then we can get it all over with.

OK. I'll try to get to it sooner than later, then.

Ta.

I'm not really sure I like the thought of there being any XEPs for which the approving body isn't either Council or Board.

These *are* Humorous ones. Maybe it needs "in consultaion with the XMPP Council Chair" specifically?

It seems somewhat self serving, but I'd be happy with direct approval by council chair, yes.

Although TBH I'm not sure what the problem with just using Council is.

What usually happens is just someone says to Council, quietly, "I'll be writing along these lines" and Council says "Fine, go ahead".

The counter to "These *are* Humorous ones." being "These *are* XEPs".

If we went with XEP Editors, we'd need to put in place some sort of rules for meetings and approval process, I think, which we don't currently have.

And being able to take a XEP through every step of the process autonomously dramatically changes the scope of the Editor team.

anyone happen to know if XEP-0027 also works for MUCs? and wether that's implemented?

27 doesn't even work for presence :)

27 doesn't work.

And no, it wouldn't work for MUC.

Basically, don't go near 27.

ok

with doesn't work for presence you mean you can't encrypt presence stanzas? ✏

You can sign presence or encrypt (but not sign) messages. That's all.

No, I mean that there's no protection against replay attacks.

It's full enough of holes that we should just stay well away.

Thus the mail I just sent to council@ about getting rid of it.

PGP for email doesn't have that either, not?

Tobias: PGP signatures contain a datestamp.

in email.

Kev, http://wiki.xmpp.org/web/XMPP_E2E_Security i've started to collect an overview about all proposals out there

xnyhps, ahh..ok

You should probably mention that OTR doesn't have clean discovery.

Unless you know the person you're talking to has OTR from out-of-band discovery (e.g. talking to them), the experience is quite horrid.

I disagree with the "Yes"es for Authenticity and Integrity with PGP.

Right.

xnyhps, it doesn't provide those?

Nope.

We should really forget 27 exists, and get rid of it.

Your messages aren't signed, any attacker can replace them with any other encrypted message.

Presumably in the other order, or we wouldn't remember what we were getting rid of.

xnyhps, that's for XEP-0027, not for email usage of PGP right?

Yes.

Tobias: It provides complete protection as long as you have absolute faith in your server, their server, and all the networking in between.

maybe i just expected XEP-0027 to be too much like email PGP

Kev, right...why do i need e2e then

:)

Yes.

See earlier question about burning 27 with fire.

+1 for fire.

s/question/comment/

!xep 27 doesn't have discovery support either it seems

at least i see nothing about disco in the XEp

Fire

It

Burn

With.

updated the table...will add a couple sentences in the section above

I also disagree with the "No" for multiple resources for OTR.

But maybe it's also not "Yes". :P

right..the detailed answer probably doesn't fit in a table cell

but i could add a paragraph above in the section of OTR to it

also wondering what version we should describe there? OTRv2 or OTRv3?

what's used out there?

I don't actually know, beyond Pidgin and Adium.

(I'd also say "Malleable encryption" should be "n/a" for PGP, as it doesn't even have authenticity. Sorry for pestering you, I can't find my xmpp.org login.)

I wonder if it'd be interesting to do a 'real' gpg spec.

it'd at least have great support for offline messages :)

It would.

And at least the methods for trust are established.

In fairness, XEP-0027 is better protection than many of the recent commercial "secure IM" services that seem to have sprung up.

dwd, to what are you referring exactly?

Tobias, Most of the new security bandwagon services seem based around similarly, or worse, flawed models.

*most* probably qualifies here, considering the ton on new services

you guys know of any implementation of RFC 3923?

I don't. I have heard people say there hasn't ever been one.

In fairness, 3923 isn't even a bad design, as far as I can tell, it's just ugly.

don't RFCs require implementation at some level?

Only to move to Draft, IIRC.

ah..ok

Which is vaguely silly - they shifted the meaning of each level while keeping the requirements largely the same.

isn't it finally time to consider one-to-one chats as a subclass of multi-user chats, security-wise? After all, you have your smartphone and your desktop connected (or connecting later) and want all your IM backlog there

btw, how did WebRTC solbe the certificate/identity management problem for DTLS?

*solve

There's a fingerprint in the SDP blob.

Zash: how is that supposed to solve anything?

users obviously will meet in person to validate those

And I don't know if there are actual certificates.

if I meet my users in person, what do I need WebRTC for?

Ge0rG: Define "anything".

Zash: anything is the set of IT security properties that a cryptographic protocol should be able to solve: integrity, authenticity, privacy, nonrepudiation|deniability, and one or more unimportant ones

Ge0rG: And a DTLS fingerprint does not?

Assuming you shuffle that securely to the other party, along with the rest of the SDP stuff

Zash: so you are assuming a secure channel between two parties, which you use to construct a secure channel between these two parties?

The connection to a common server, yes. :)

Zash: a trusted common server that does not manipulate your packets

Yes.

If you don't trust the server, when it's the server providing the application, you're in some amount of trouble.

That.

ok, now that's where XMPP is different from WebRTC

Yes.

does WebRTC support federation?

Different layer.

Or, kinda.

(actually, that question does not matter.)

I just realized that me trusting my own server does not help at all in establishing a federated session through a different, untrusted, server

who can contribute to the xmpp.org wiki?

A bunch

You, if someone gets you an account :)

ah, so the formal requirement is "get yourself added"

right

basically you just ask for an account in the jdev chatroom and some admin will likely create an account for you