XMPP Council - 2013-09-12

Why, Dave Cridland, why?

Zash: disappointed he joined Twitter?

Who what why where how?

re http://logs.xmpp.org/council/130911/#19:47:26

Zash: http://logs.xmpp.org/council/130911/#19:47:26: Chatroom logs for council@muc.xmpp.org (Wednesday, September 11, 2013)

Zash, Certificate pinning via TACK?

Zash, Seems like a substantial amount of work for little gain. You can get the same general protection from DANE - that is, protection from third-party CAs issuing bad certs - with a lot more, for less effort.

Dave Cridland: But TACK seems to have a bigger marketing budget!

So it'll win!

:(

The advantage of TACK is that is handles this particular pinning case without infrastructure support. That's certainly useful, of course.

ralphm: Why is Thijs "xnyhps" not on planet jabber yet? :)

but TACK doesn't seem to be implemented in the foreseeable future, or is it?

DNSSEC deployment isn't that fast either

Tobias, TLSlite implements it I think. I assume so anyway.

Zash, That *seems* faster to me.

TLSlite, what's that? the python tls implementation

Something like HSTS for XMPP should be fairly simple ...

is HSTS really needed? TLS is the default in the XMPP world, unlike the HTTP world

The intent is to protect against future downgrade attacks.

Right.

Zash: because I'm slow

Dave Cridland, downgrade from TLS to non-TLS?

Zash: and had a funeral yesterday

Tobias: Strip the starttls advertisment.

ralphm: Oh, sorry. No hurry.

ie, I connect to my server, and get my connection policy blob. Next day, I connect to my server, and it has no TLS, but my connection policy blob says my server always offers TLS, so I ditch the connection.

right

but shouldn't clients complain anyway if TLS is not available?

We could just never allow non-TLS if TLS succeeded once.

Zash, right..or that

And never allow invalid certs if the cert was valid once

etc

Zash, There are operational issues there, I suspect.

could completely life in the implementations

without need of standard

Yeah

Something like HSTS would be an explicit approval of doing that.

I'm not sure we really need it

Zash, More importantly, that's a hand-waving exercise - there's no way to know if your clients support that, and there's enough kinks and choices that a pathway through to some kind of downgrade might be important.

For real entertainment, we could have a XMLSec signed document with the connection security policy in it, and then be able to access that via a number of methods. But hey.

iq:get after authentication.

I win.

aren't you supposed to be holidaying? ;)

Having DANE records published also implies that tls should be supported.

I was thinking in terms of iq:get from other servers and such.

Zash, Yes, this is certainly true.

Tobias: Never reveal in public when someone's not at home.

Tobias: And yes, although I'm back home now.

Kev, ah.oops.right..sry

Tobias, It's OK, I'm sure Kanchil keeps an eye on the place.

Dave Cridland, sure

cool...drag and drop invite worked for waqas :)

Hello

waqas, we're just discussing security improvements to XMPP

waqas, which are?

Well, there are multiple separate aspects of the XMPP network that are weak. Bad clients (cert verification issues, cipher suites, etc), bad server deployments (SSLv2, bad cipher suites, PLAIN over unencrypted), server software defaults, etc

Then we have the separate class of security missing entirely from XMPP: encrypted jingle, e2e encryption, etc

Some of this requires activism, while some requires standards work

bad ciphers and so probably falls into the activism area

Something like a validation service might help the server deployment side of things a lot

I think an Informational XEP here might be in order.

I'm +1 to that

also i'd interesting to have some kind of MITM protection, i.e. if your usual cert is suddenly replaced by some other strange cert (i know it sounds vague)

It would also be nice if support for that XEP was required to get on the xmpp.net server list :)

waqas, the xmpp.net list is a whole other topic...it doesn't seem to really scale

Tobias: I think an Informational for that is interesting too.

A validation service would help it scale to some degree. For better or worse, a lot of public XMPP deployments want to be on that. If the XSF can use that to upgrade the security of the XMPP network, that's a good thing IMO.

another thing is that server implementations generally don't alert admins about bad certs

Kev, what would be the rough gist of it?

Tobias: Sounds too much like work for a holiday :p

You've seen PSA's new I-D on XMPP and TLS?

Only that it exists.

Kev :P

That covers cyphers, but not pinning stuffs, I think?

Right, it addresses much of waqas's easily addressable concerns.

I'll read it at some point :)

It seems like a good start

waqas, But yes, we should require claims of conformance to various specifications to be listed, I think.

Does anyone know how bad compatibility issues are with dropping SSLv3? Is most everything supporting TLS1.0 these days?

waqas, Most of the figures I've seen relate to browsers. I don't know about XMPP, I suspect we're generally TLSv1.0 and up.

I also want to note that SSLv3 is entirely not supported, spec-wise.

and never has been for XMPP 1.0

I assume most of you have read xnyhps's (Adium dev) recent posts regarding client cipher suites?

I've not. Link?

https://blog.thijsalkema.de/blog/2013/08/26/the-state-of-tls-on-xmpp-1/

The three "State of XMPP TLS" posts: https://blog.thijsalkema.de/

He has been gathering data on what cipher suites, etc different actual clients support

This sort of information can feed directly into client+server software configuration defaults, and given most deployments don't bother changing defaults, would help improve security

It also gives data required for pestering software vendors to fix their stuff

Also, jabber.org might be able to do a whole lot in getting deployments updated. If jabber.org disabled certain bad things, e.g., SSLv3 or export ciphers or required TLS crypto for everyone except Google (can the software pull that off?) or Google went away, etc, other deployments of both servers and clients would simply be forced to follow.

Few compatibility concerns in XMPP land has been as strong as the desire to stay compatible with jabber.org, and this is a fact which can be used to force change

*have

waqas, I think M-Link's manuals are publi, and as such, I think I can safely say that TLS options in M-Link are global, and not tied to peer controls - TLS requirement and certificate pinning are at the peer level, though.

waqas: the problem with whitelisting GTalk is that you have to do it based on the resolved host, because there are so many domains there.

right...or delegating new user registrations to servers which have decent security

I think even Prosody doesn't support it in that way.

Yep, which is bad, but such a thing would be strictly better than what we currently have

ralphm, Ah, good point. So jabber.org couldn't simply whitelist Google; it does these things by name.

And I freely admit it's a bit of wishful thinking, which while possible, isn't implemented anywhere

ralphm: Plugin could do that ;)

Of course, this is one thing we all thought we could do with Google dropping S2S, except they kind of haven't.

And I suspect they might not for a long time

Heck they might decide to never drop it, and we'll have this insecure s2s situation forever

Zash: of course, but the existing config support for that only works on domains

I notice mention of HSTS in the room history. That's a nice-to-have thing. We don't have a spec like that, but a client notifying me when it connects to a server and has stuff changed (different cert, but more importantly: weaker security), would be useful to me at least

I'm not entirely clear on what this discussion is. Part of the council meeting? Just random discussion after it? :)

waqas: Do you think we need a HSTS-ish spec?

spec/protocol

waqas, Random discussion because we'd not left since yesterday.

Could the current HTTP-ish HSTS spec be used in some way? I don't recall what it looked like. Was it just an HTTP header? If so, a stream feature would be all the spec work required?

waqas: Header saying don't accept plain connections for N time

so, everyone here, if you are planning on going to the XMPP Summit in Portland, and haven't signed up in the wiki yet: WHY NOT!

ralphm: Expensive and far away.

And if you're not coming, I think the six of us who are will find a really good bar and whole up for the evening.

Hole up, even.

Dave Cridland: MattJ and I don't drink… we'll just be staring at you the whole time

waqas, +1 on that

Zash: to be sure, I wasn't asking why people were not planning to come.

Zash: it appears that we have a bunch of people that are going to, but we don't know about them

Zash, was fosdem acceptable regarding the costs?

waqas, You're coming?

Dave Cridland: Well, I'm in the US, and have a realtimeconf ticket, so: probably

Tobias: I think so. But I skimped on accomodation costs by staying with friends.

waqas, US must have a nice visa process ^^

Tobias, Yeah, but he has to get through TSA with that name...

Tobias: Surprisingly easier than Belgium. It was a lot more well-defined.

Dave Cridland, he could just put a turban on and would be fine

And the TSA was being weird both times I arrived. The security seemed to be missing entirely at JFK.

JFK can be hit and miss. It's usually horribly crowded for me, though hey seem to be rebuilding it.

I never went there

No scanners, no questioning, no baggage checks (I literally could have walked out with anyone's luggage both times), I saw no real evidence of the TSA

AMS->PDX FTW

PDX?

Tobias: Portland, OR

ahh

ralphm, I'll be CWL->AMS->???->DCA, and DCA->PDX, then PDX->AMS->CWL.

oy

Dave Cridland: AMS->PDX->SFO->AMS for me

m&m: hi

waqas: go sign up at http://wiki.xmpp.org/web/Summit_14

ralphm, Right; I can't fly into DCA from outside the US, and refuse to fly into Dulles, so...

ralphm: http://wiki.xmpp.org/web/Summit_14: Summit 14 - XMPP Wiki

Well, I need to check out of this hotel, was just about to leave when Tobias invited me here, so I'll be on a train for an hour. Hopefully my input was useful in some way :)

waqas, Sign up first.

Done

waqas: what Dave Cridland said, because we can then maybe still do a hotel package deal

Ah good, I was wondering about what to do about a hotel

That's now 6 awesome people. And me.

I won't be able to make it.

I'm running off now folks

Bibi.

Kev: good save regarding Dave's ponderance

Yeah, thanks guys.

Dave Cridland: You're awesome.

For what it is worth, I did include you in my oob assertion.

I'm going to be missing out myself

would have been good to hang out with such awesome people

and Dave

hibyehi stpeter