XSF Discussion - 2016-01-07

MattJ: well yeah, Jaiku was acquired by Google, used as a vehicle to test app engine and then dismantled. There are some bits and pieces (idea-wise) in Plus.

Flow: If you can improve the xepdiff tool, I'm sure no-one's going to object. It works pretty well though (and has been useful for years), so I'm not going to say much bad about it :)

Flow, That's the RFCDIFF tool. It works on plaintext only. We could build a plaintext rendering of XEPs and use it that way.

Kev, Did you notice discussion about mixed content in the diff tool yesterday?

Panic not, my name is now on the list. And unlike 40% of Council, I can follow basic specs.

I did not.

I just saw Flow saying I wish XEP diffs would be like that: http://spec.commonmark.org/0.22/changes.html 22:23

Ah. One of the CSS files is referenced with a full HTTP (no S) URI, so it doesn't work with HTTPS.

Kev, http://logs.xmpp.org/xsf/2016-01-06/#11:08:44

Tobias: Are you still maintainer of the difftool? :)

Kev, likely :)

See above :)

Although if we've got any sort of documentation of where the Git repo for it is and how to deploy new versions, I can probably sort out a fix in a bit (I'm about to go unavailable for an hour).

git repo? :) i think your hopes are too high

it's a collaboration of waqas and mine, should on perseus somewhere...but daisydiff hasn't been maintained for years...so maybe it's worth looking at alternative for the diffing

Tobias: someone should introduce you to the wonders of Distributed Version Control Systems

Well, OK.

I might try to extract the code from perseus and put it up on the XSF's github repo, then.

Tobias/waqas: Assuming you're ok with that.\

AFK a bit.

the code extracting the two different XML versions of a XEP shhould be nicely reusable

MIX §5.1 is "Common User Use Cases". What about posh users? Does one do things differently?

Kev: If it was me, I would simply replace to the XEP format from XML to CommonMark (with annotations). Then good difftools come for free :)

Kev: Sure

dwd: It would be pretty useful to have a RFCText version of XEPs…

waqas, XSLT has a text output mode, so it's possible. Could even have that output to CommonMark.

waqas, Or a transform from XEP-0001 schema to xml2rfc, of course.

Daisydiff has an intelligent (i.e., structured) HTML diffing mode. My primary contribution to daisydiff was major optimization, so that the PubSub XEP didn't take tens of gigs to diff.

Daisydiff does optimal diffs, so had O(n^2) complexity, and was too object-creation-happy.

dwd: does the existing xslt files have a nice text output already?

I wrote a thing that spits out markdown earlier

I've posted the the link to OX on hn: https://news.ycombinator.com/item?id=10857537

Is the MIX ProtoXEP acceptable as Experimental given that there are so many white spots?

Flow: I think so, given that the bits that aren't white were meant to be sufficient to get an implementation.

Kev: sounds reasonable, was just wondering

So essentially the white bits are useful in giving an indication of what's to come. We could have just left out the white bits, had a minimal XEP, and added new headings later as we wrote the new features, but I think what we've done is preferable in this instance. In another instance I might have a different opinion.

I also put TODO: List Discussion in there in a few places, which is very unorthodox, but I think was a good idea because I wanted a) list discussion and b) anyone implementing to understand likely future changes.

Kev: this list discussion mean there have already been discussions somewhere ? Or it's just a placeholder for future discussions ?

Meaning that there are some large questions that still need answers, and so I'd like discussion to happen on the lists.

And, probably, at the Summit.

I would be happy to do an experimental implementation for the client side, but a server component would help.

I'll be trying to schedule one of those as soon as I can, but it's not going to be imminent.

Flow, I'd rather have XEPs with large emtpy spaces marked "TODO" than no XEP.

Flow, Obviously at Experimental. I'd hope that by Draft it'll be more complete...

is anyone familiar enough with XEP-0357: Push Notifications to explain the rationale for sending any sensitive data over push at all?

vs a simple 'wake up and check your xmpp server'

It's optional, right?

moparisthebest: You won't be able to wake up to fetch the rest of the data until the user asks you to.

Zash, yes, but why even make such a horrible decision optional?

Because use cases

Kev, what do you mean? a push message wakes up the xmpp client to do network stuff right?

moparisthebest: Not on iOS.

Zash, yes I'm asking about what use cases it could possibly have?

I would guess that it depends on the platform

moparisthebest, iOS is rubbish, basically.

so it's so on ios it can display 'USER sent MESSAGETEXT"

instead of 'you have a new message' ?

dwd on some areas yes.. but still .. better in so many others. :-)

who ever thought using a network router OS in the mobile realm…just crazy

Tobias, Oh, *that* IOS is OK.

I still tend to think a simple 'You have a new message' would be much more preferable giving the security implications :/

moparisthebest: And that can't be decided by the implementers?

seems kind of dangerous to allow that to be decided by implementers

FWIW I wrote an SMS based "app server" that just sent "You have chats"

xmpp enforces encryption between all links, but this xep encourages unknown encryption on 3 links and 2 servers ?

Zash, call this number to listen to the messages you've received while offline :)

Tobias: Ooooooh, that'd be fancy :)

ok, new idea, if ios clients want to display messages, why not still encrypt sensitive data?

client could send their xmpp server a public key with which to encrypt things before sending over the push network?

Tobias: Perfect for me who isn't usually that comfortable with phone calls at all

Zash, thought so...finally you can use up all those "free minutes" :)

Does iOS let the client render the message?

Zash: No.

It can't process it at all until the user taps on it.

moparisthebest: So that's impossible.

Unless you do the decryption in your head, yeah. :P

How about "if you care about privacy, don't use iOS"?

the more I learn about iOS the more I'm convinced it's the absolute worst excuse for an "OS" in the world

I figured there were reasons for including terrible stuff like that in the XEP, I just couldn't figure out why, now it makes sense :)

http://xmpp.org/extensions/xep-0357.html#security

I saw that, but allowing bad decisions at all, even if accompanied by security considerations is a bad idea

and with only knowledge of how android works I didn't see a reason for it

moparisthebest: that is correct, you don't need xep357 on Android

Flow, apparently you do for android 6+ I recently learned... :(

google is racing apple to the bottom I guess

moparisthebest: not true, you can request to whitelist your app

... "request to whitelist"

Flow, apparently it pops up an ugly confusing dialog the user has to 'consent' to, something about lowering battery life

I mean, that's what I'm personally going to do, I don't have any google apps and therefore no push on my phone

but an app without technical users like conversations probably can't assume everyone is going to do that, and therefore must implement xep-0357, but hopefully with no data going over the line :)

Flow: Well, you can't be sure that you're not going to get terminated, so 357 still makes sense.

Kev: That heavily depends on your use case

Assuming your use case is 'have the user able to get notifications of new messages while the phones in their pocket'.

I achieve good results doing a check for liveness every 30 minutes

How do you check for liveness?

server ping

xep199

But the server pinging you doesn't help if you've been terminated.

Kev: reconnect if the pong didn't arrive within a reasonable amount of time?

The server can't initiate the client starting!

No I ping the server

How, if you've been terminated?

Flow, Kev means process termination, not connection termination

Then I reconnect

How, if you've been terminated?

START_STICKY

Android will restart the Service component if it's started sticky

usually wihtin a few seconds

sometimes within a few minutes

I've never had conversations terminated by android personally, not sure if it's common elsewhere

Unless the user's using their web browser for a long time (or other memory-hogging process, but it's usually browsers from what I understand).

what we need is an xmpp-based push service, where part of the design is end-to-end encryption across it

then it can come by default with cyanogenmod and other roms, or be installed on rooted phones, and we are good

I accept that may be a reasonable trade of. I'm not convinced it always is, and in those cases it isn't, 357 continues to make sense.

+f

"xmpp-based push service" ...

Kev: It mostly comes down to if your users are ok that sometimes messages arrive a bit late, 30 minutes in the worst case. But GCM also doesn't provide any gurantees about when the push is delivered. So the trade off is perfectly fine for me. Plus I don't have to depend on third party services.

But they are or were all xmpp based. And XMPP itself is push, since TCP is push. I don't like the word "push" in this context, it's confusing.

Flow: Fair.

Zash, probably are, it's a good choice, but I'm saying fully open source (ie you-can-run-your-own) and encrypted end-to-end always, ie client tells pushing service a public key to encrypt to, only fully encrypted messages transit push service

It's not about open source or even the protocol. It's about control, which Google and Apple does not give you, so there can be no nice solution here.

the push service sdk would be easy too, it'd just be a minimal xmpp client, or anything capable of xmpp, could even integrate in the open source gapps replacement for android apps to use the same

And that's why 357 is ok. It's a compromise.

Even the architecture of XMPP itself is a compromise, one that happens to work really well.

google does, something like this could come with cyanogenmod and all the other roms?

you could use it on a 'jailbroken' ios device too I guess

so does http://www.mitls.org/pages/attacks/SLOTH mean SCRAM is totally broken? and therefore XMPP authentication with untrusted servers?

though most things I see use PLAIN anyhow :/

moparisthebest: No. It just means SCRAM-PLUS is not as secure as it should be.

But we knew that already

ok good then :)

See also https://secure-resumption.com/

have we all discussed PrivaTegrity here yet? http://www.wired.com/2016/01/david-chaum-father-of-online-anonymity-plan-to-end-the-crypto-wars/

Zash, doesn’t the weakness exposed by sloth require you to use the same credentials on a trusted and on a malicious service?

mathieui, yes that's how I read it

it's not a good security policy, but you know many people do it all the time... :(

mathieui: Huh?

XEP-0369 - quite a good number.

moparisthebest, it also requires a man in the middle from the malicious service, (in order to sync the tls-unique) afaik

stpeter: sounds like that council mention in the article is a job for the Elders of the InterNet

dwd: numberist

ralphm: that doesn't make dwd any less right.

mathieui, yep

https://en.wikipedia.org/wiki/369_%28number%29

magic number!

The only number better is XEP-0248, since that's increasing powers of two.

dwd: I quite like 313

It's a happy prime

until 968 XEPs from now that is

I'm happy with both 313 and 369.

mathieui: I'm not sure what you mean that about same credentials, or how it applies.

Zash, SLOTH allows credential forwarding with SCRAM, where SCRAM uses tls-unique to prevent credential forwarding

stpeter, I'm sure the 5 eyes would be quite happy with PrivaTegrity, they'd only have to hack 4 other countries to ex-filtrate their keys and they'd have everything they always wanted :)

I loved it when I found out 313 was a palindrome in binary as well as decimal

and a prime number

and a happy number!

And that :)

moparisthebest: yeah for sure

and for literally the millionth time, criminals will just use non-backdoored crypto anyhow....

Question is, does TLS 1.3 fix tls-unique?

that article mentions the md5 fixes for tls 1.3 but nothing about tls-unique, so I'd *guess* no

As it was already broken by that 3 handshake thing, which IIRC did not require finding a collision at all

the 3 handshake thing says Mitigations pending modification to tls-unique or adoption of new TLS extension

Which isn't there yet afaik

given the truncation of sha256 causing the SLOTH problem too, hopefully tls 1.3 will do SOMETHING about it?

https://tools.ietf.org/html/draft-bhargavan-tls-session-hash-01

moparisthebest, tls-unique is on the rocks anyway.

dwd: on the rocks?

Zash, In as much as we need to replace it with tls-session-hash or something.

dwd: I thougt the idea was to have the algorithm be replaced by what tls-session-hash says

Either negotiated as an extension or replaced entirely in TLS 1.3 ✏

I've looked at tls-server-end-point but it requires more asn1 introspection to be added to our tls library. :/

I thought that was just a hash of the server cert?

Well, the server cert in its DER form, at least.

I like things that hash a der :)

dane/hpkp etc

dwd: But the hash algorithm is determined by the hash used in the signature algorithm.

as long as it's sha2+ it's fine

Ah, I see.

Yeah, I think you can cheat and always use sha256, but it'll break if it's signed with rsa-sha512

It would have been easier if the hash algo was fixed, or determined by having eg tls-server-end-point-sha256 and tls-server-end-point-512 etc

But then it's tricky since there's no negotiation, so client's can't know if anything other than tls-unique is supported

Hi guys .... A small mistake in https://xmpp.org/extensions/xep-0369.html MIX has been accepted. :)

Version 0.1 (2015-01-07) Initial published version approved by the XMPP Council. (XEP Editor (asw)) Version 0.0.1 (2015-10-12) First draft. (kis/psa) END

Year should be 2016 ;)

Hi guys .... A small mistake in https://xmpp.org/extensions/xep-0369.html MIX has been accepted. :) ​ Version 0.1 (2015-01-07) Initial published version approved by the XMPP Council. (XEP Editor (asw)) Version 0.0.1 (2015-10-12) First draft. (kis/psa) END ​ Year should be 2016 ;)

Heh

Heh.

thorsten: Yeah - that's fixed now (might need a hard-refresh though). The copyright date was also still 2015.

Ash: and I didn't see the copyright ..... Great Ash. ;)

It's far too early in the year still for this kind of thing! Thanks for spotting :)

It's still early in the year; we have not had enough coffee yet this year to be thinking about these kinds of things (pretty sure coffee works that way on any time scale).

Ash: SamWhited just wanted to help a bit ;)

I have a serious problem. I'm out of coffee and it's too cold for me to want to go out and buy more. I guess I'm doomed.

can you reuse the old coffee grounds until it warms up enough?

Zash: that's what's missing: coffee delivery service for offices

moparisthebest: I'll find a button place in conversations for it ;)

moparisthebest: That's worse than the emergency instant coffee I'm currently surviving on

eek I'm not convinced it's WORSE, maybe the same

Zash: u drink what?

And my colleagues want to kill me when I out some hot water in my cappuccino to stretch it !

Out=put

That's a brilliant idea… I wonder if there's a service that delivers coffee around here; I would love having a HipChat addon or something for that.

I would be broke very quickly.

Zash: There's no such thing as too cold to go out and buy coffee.

(Though that's easy for me to say while it's 7°C outside.)

Can't see the attraction of coffee, myself.

But if I ever ran out of tea the world would end.

dwd, british?

Of course.

or cricket

MattJ: Isn't that illegal for you people?

Or bacon, though, which makes you officially weird.

dwd, yea that's pretty much the most british-sounding thing I've ever heard, you guys really like your tea

I was sooooo close to saying "or ribs"

https://www.bountysource.com/issues/25371199-feature-request-message-search

So, I kind of have an implementation of this new OpenPGP for XMPP XEP. :)

And an echo bot which decrypts the message and encrypts an answer with the same body.

I didn’t implement verification yet, nor key publishing, I only have iq/presence/message encryption and decryption.

(In slixmpp.)