XMPP Council - 2013-08-21

The only thing I have on the agenda for today is the list of purgatory XEPs Peter mailed 'round.

Hi Ralph.

10mins:)

Kev: I always aim for :00, so I'm surely on time

Seems reasonable.

Jtalk's muc is still a bit buggy

greetings

Guten tag

Goede dag!

:)

Interestingly jtalk lists all my multi session nicks

m&m is in the JSON WG meeting all day and won't join us here

IIt is time.

psaintan: He said last week he couldn't make it - although I was hoping he'd suggest a better time.

1) Roll call.

M&M sends apologies.

I'm here.

here

Here

psaintan: fancy

Tobias leaves in disgust.

:)

Still one left, I guess

Still there

2) Stuff stuck at proposed.

XEP-0152: Reachability Addresses XEP-0220: Server Dialback XEP-0288: Bidirectional Server-to-Server Connections XEP-0297: Stanza Forwarding XEP-0301: In-Band Real Time Text

Does it seem sensible to vote on them going to Draft next week?

I need to review the 301 diff (Please, everyone else, do feel free to do a review and comment!).

fippo sent me some editorial nits about 220 and I will process those ASAP

I keep hoping to have a chance to do a cleanroom implementation of 220, but then I don't get around to it, so that's no reason to delay.

we can ping fippo about 288

yeah, dialback has been stable for a long time :-)

Bidi not though

So, everyone ok with just voting on the lot next week?

Yes, I think so

just out of curiousity, apart from GTalk connectivity, how much do we still need dialback?

Fine with me

I have some small modifications to make to 297, so I'll push those this week

ralphm: We might not want to use the in-dialback proof method, but I think we still want to keep the dialback protocol stuff around.

ralphm: well, POSH and DNA and such actually use dialback for signalling, about piggybacking so I think we'll keep it around for a while longer :)

At least from what I understand.

right

OK. So that's all on the agenda for a vote next week.

psaintan, can they function without dialback at the moment?

Did I miss anything for this week?

ProtoXEPs or whatever.

I knew about all this, of course, but still wondering if the landscape has changed enough to do everything with regular tls/sasl

MattJ: see http://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/ and provide feedback on the xmpp@ietf.org list :-)

ralphm: for initial connections, yes

ralphm: for piggybacked domain pairs, unclear

Shoving SASL exchanges into the middle of a stream would be somewhat unorthodox.

OK.

3) Date of next.

psaintan: is this a point of attention in the XMPP WG

SBTSBC?

?

although (AOB) I would like to start pushing the communityforward to fully encrypted hops

ralphm: the DNA stuff is

right

I'll take that as a 'yes' to SBTSBC, then.

4) AOB

Kev: yes :-)

Kev: yes

Yes on the time

So, SEX day. Please, for the love of all that's good, let's not call it SEX day.

Kev, you could just have the whole meeting yourself :P

+1

and I'm replying to that post...

huh?

oh

I realise as geeks we have the humour capabilities of a three-year-old, but still.

psaintan, see Simon's latest email

I started reading that but hadn't gotten that far

agreed on the naming!

Hehe

psaintan: Do we know what 'fully encrypted' means?

Kev: TLS anyway

channel encryption

with cert checking

Cert checking...for what?

CAs?

RFC 6125 stuff

Kev: I guess we're done here?

Yeah, I'm happy enough that this is a tangent.

Thanks all.

:)

psaintan: So, this means that any server not automatically fetching certs and doing OCSP and stuff should stop federating, right?

s/certs/CRLs/

Thanks

well, no one does OCSP as I understand it

That was somewhat my point.

Kev: I know you're tired and overworked, so please just s/fully// and we'll move on

Peter, and crls?

I wasn't being entirely belligerent. If we want to have a big 'turn off encryption and partition the network' event, I think we should have a reasonable handle on what's involved.

well, sure, people should do all that stuff, but at least doing RFC 6125 checks is a good idea

What servers do crl?

Tobias: Fully, without having to fetch manually? Just M-Link of which I'm aware.

And even then, only by configuration I think.

I'm not necessarily in favor of a flag day, but it would be a step in the right direction if several of the larger nodes required TLS and proper certs (and we had helpful HOWTOs in place so that admins of other servers could get up to speed)

Yup. 3rd party fetching

I'd suggest we just go with 'require unchecked TLS' first.

And this does effectively blackhole gmail, which isn't something I'm entirely comfortable with..

CRLs and OCSP are two solutions to a problem that might be solved in other ways (e.g., shorter-lived certificates), but that's a wider discussion

maybe we wait until Google turns off federation

Peter, nobody knows when that is though

sure

so perhaps we need to take the lead

we don't necessarily make it permanent at first

we can experiment as people did with IPv6

I don't think anyone (significant)'s tried promoting IPv6 by turning off v4 though, have they?

heh

I'm not anti-TLS-on-S2S, although I realise my "Let's think this through" sounds a bit like it.

I'm in favor of c2s first of all

that's an easier step to take

That one is much easier.

yes

and will help us isolate some bugs, fix some software out there in the world, etc.

I'd be happy with someone coming up with a list of steps on the road to secure XMPP, and it probably looks a bit like: No PLAIN/78 without TLS No C2S without TLS

Require SCRAM-SHA1-PLUS with TLS where possible.

(e.g. it's not possible while backing on to AD or whatever)

I'd be very happy to sort out (1) on j.org, finally.

Then plan to do (2) in a couple of months.

I think (3) might be a little optimistic.

that seems eminently reasonable

I wonder which server products have configuration bits for these things

and whether we need to figure that out for the more widely-deployed servers

Prosody already disallows PLAIN (or legacy auth, if enabled) on unencrypted connections - and most clients do anyway

I think it'd be good to sort out a roadmap to security.

Kev: yes

And then we can let the vendors have this, so we know that software can do it.

and has a config option to enforce TLS ✏

And then gently encourage admins to move towards it.

we might have carrots and we might have sticks

MattJ: M-Link has a config option to re-enable PLAIN without TLS, and we've got that switched on on jabber.org

xmpp.net might have a role to play here in reporting and self-testing

Kev: why?

I do wonder if prosody-users and buddycloud-dev are the right venues for the discussion :-)

ralphm: Because when we initially deployed, there were so many users that suddenly couldn't connect.

Maybe, three years on, this wouldn't be the case.

Kev: surely you have statistics on this?

Kev: yeah, a lot of those users were on old OS X releases IIRC

ralphm: Could generate stats, but I don't have any to hand.

oh

But we can't generate stats or whether those users have just configured their client in a stupid way, or don't have another option in their client for some reason.

But anyway.

<3 stats

I'm entirely in favour of just making an announcement once the migration dust has settled and disabling this option on jabber.org

Kev: yes, I've been waiting to bring up such issues until after the migration

And then making another announcement and after a couple of months requiring TLS.

yes

I'd /like/ to then require SCRAM-SHA1-PLUS, but that's a bit trickier :)

:)

indeed

one step at a time

Although at least Tobias and I are using clients that'd work fine with. Anyone else? :)

I think we all agree on the goal, but we need to be prepared and think through the various issues that will arise

psaintan: 'tis all I ask.

Kev: I use Swift for stpeter@jabber.org but in Psi at the moment

psi's just got scram without plus

and flipping multiple switches at once is a recipe for not understanding what's causing various problems

SCRAM without PLUS isn't much better than DIGEST-MD5 :)

Kev, interop wise it does

Or, at least, it's the -PLUS magic that's relevant to the TLS conversation.

Sure

Kev: everything is much better than DIGEST-MD5 in my humble opinion

even DIGEST

eh

PLAIN

heh

In terms of interop, yes.

In security properties, maybe not.

and in terms of bat shit crazy omgbbq who the hell thought this up

Then DIGEST-MD5 > *, yes.

Although I think this is more just a case of 'things have got better, we're better at doing this now'.

Kev: no

Kev: i.e. your colleagues (among others) were already discussing all the bad things in DIGEST-MD5 over a decade ago over in the sasl wg

I wonder if at any point Simon's going to move this discussion somewhere a bit more appropriate than prosody-users.

Heh

Yes, operators@ would have been more appropriate I think :)

It's a question of deployment, not implementation

operators@, or if he wants it to be XSF-endorsed, members@

(at this point I think all popular implementations are capable of what we're discussing)

Could be.

Although I think doing some self-signed CA leap-of-faith-with-dialback stuff would possibly be better than public-CA-based PKI stuff.

Depending what the things people are concerned about are.

OK, I've incorporated fippo's feedback on 220

but yeah, agreed on operators@

brb