XMPP Council - 2012-04-04

meeting in one more hour (ish)?

Nope, now.

I suck.

Thanks for the poke

heh

no worries

I'm in GSoC time.

(-:

But anyway.

1) Roll call.

presente

MattJ / Tobias: Highlight.

present

Boo

gift

offering?

Righty

2) XMPP WG report.

linuxwolf: You fancy giving one? :)

sure

The WG meeting in Paris, one week back

major topics are end-to-end encryption, domain-name-assertions, and i18n

roughly the same topics as 5 years ago it seems :)

there is a draft for a new proposal to e2e, which puts key management into a protocol, and is trying to re-use the work from JOSE (JSON Object Signing and Encrypting)

Tobias: basically (-:

I finally know what JOSE is

(-:

linuxwolf: So long as it doesn't need us to rewrite XMPP in JSON.

no!

the proposal has been received favorable reviews to date

the crypto bits are encoded with some sprinkling of JSON, but the XMPP stuff is still XML

OK.

it was either that or ASN.1

no one born after 1970 wants to use ASN.1

wheeee..ASN.1 :D

:)

Right.

if you're interested: http://tools.ietf.org/html/draft-miller-xmpp-e2e

there'll be an update to that sometime this month (-:

Ta. I'll have a read at some point (not right now).

DNA ...

so, after floundering about with non-discussion ...

… an approach is starting to form around a layered approach

1) determine alternate trust algorithms for certificates

2) use stream:stream headers and/or dialback for asserting names (then use the afore mentioned prooftypes)

there's been discussion for two alternatives over PKIX: https/.well-known and DANE

DANE is a DNS-based protocol, essentially you get the target cert, signed indirectly with DNSSEC

the TLSA RR is signed, but the cert can be almost anything: self-signed, ca-signed, trust-anchor, etc

linuxwolf, alternatives? can't PKIX, https/.well-known and DANE co-exist?

they can

and HTTPS's S is based on what, PKIX?

and a server (or client) will likely need to implement all three

the HTTPS/.well-known is simply the target certificate (or maybe also a trust-anchor) at a specific path through HTTPS

the trust established if you can trust the HTTPS connection

PKIX and DANE are likely to be implemented in TLS libraries in future, right?

Tobias: HTTPS:/.well-known is basically "Yes, we're not solving any problems, but we're saying they're not *our* problems, so that's fine".

in all cases, the target cert would be the hosting services cert (e.g. talk.goole.com or webexconnect.com) but obtained from the target domain (e.g. example.com)

PKIX is already implemented in OpenSSL

linuxwolf, right...wrongly phrased

DANE is likely to be implemented in some DNS libraries

but just to get the cert

linuxwolf: *Some* of PKIX is in OpenSSL, right?

you'll then feed that into, say, OpenSSL to complete validation

PKIX also includes revocation, doesn't it?

Kev: it depends on what version of OpenSSL we're talking about

it does

And OpenSSL doesn't do revocation checks for you.

it can do some

Does it?

k...and the HTTPS way will probably always need to implemented directly by XMPP client/server devs

1.0 can process a CRL chain, if it's local

Tobias: most likely

as I see it: HTTPS would be implemented "now", and DANE would come later

linuxwolf, is DANE so far away *now*?

long-term, DANE is probably the better technical approach, but it's not exactly deployable yet

it depends on who you ask

yeah...i've asked my ISP and he said ask again in a month ^^

there are more and more DNS resolvers and nameservers supporting DNSSEC, but only for the common TLDs

right

outside of .com/org/net, it's not available

DANE has not finished IESG Last Call, so there's a lot of people holding off on implementations

but requireing HTTPS support for XMPP clients/servers

/shrug

HTTPS implementations are everywhere, and if a server supports BOSH, it already supports HTTP

adding HTTPS is not *that* much more work, unless you did everything by hand

but then again there are a lot (maybe even well tested) ready to use implementations for it

exactly

If a server supports BOSH it supports being a server, not a client

plus, a lot of clients end up with HTTP libraries for things like updating and grabbing images and whatnot

I think it's a much more nefarious problem than that.

but *shrug*, Prosody does both already

MattJ: true, but like I said there are lots and lots of HTTP libraries around

It's one thing "supporting HTTP", it's quite another getting this into the trust checking for the XMPP session.

But anyway.

Is it really?

Kev: well, gotta get there somehow

Harder than anything else?

The trust checking is going to change anyway

right

MattJ: Harder than PKIX, which is already required, yeah :)

PKIX isn't good enough already, so *something* needs to be done

Right

exactly

So, do you connect to the XMPP server, ask for the cert, then see it's not right, so go on to check over HTTPS?

both DANE and HTTPS are essentially "does this cert match", without the need to go through the nitty-gritty subject

If both certs are 'bad', but behind the HTTPS cert is the .well-known for the XMPP server, do you present the HTTP stuff to the user and ask them to trust the HTTPS? etc.

Kev: that's roughly what I was thinking

I'm not saying these aren't resolvable problems.

I *am* saying this is a lot more unpleasant at the edges than "Well, there are plenty of HTTPS libraries, so we just use those" makes it sound.

Sure

Kev: it's a detail that does need to get worked out, but frankly the HTTP people have done a lot more with it than anyone else

Right, probably.

So, moving on :)

anyway, comments on the xmpp@ietf.org mailing list are most welcome

the last one is i18n

Precis is finishing up its definition of the framework, and stpeter has a draft for 6122bis based on that

but, there are a lot of dragons to work out, and we're suggesting some sub-profiles for specific things, like MUC nicknames

so a resourcepart would accept just about anything, but usage with MUC would be more restrictive

some discussion on how one might go about enforcing and discovering such rules (which are seen as locale-specific) was thought about

a lot of 6122bis is waiting on precis, which is progressing … albeit slower than others would like

and I think that about sums up the actual meeting

The "others" who don't like the speed aren't very vocal in helping resolve issues (afaics)

there is a proposal from a group in Japan for alternatives to DNS SRV, and they'd like feedback on it

Not that the issues are easy, but that's why it's slow

MattJ: essentially

well, that, and it's really a cultural problem we're attempting to solve with technology

so there may not actually be a right way to do this anyway

Indeed

the precis meeting ended with "maybe we need a new area directorate for internationalization"

heh

yeah

oh, one last point on DNA: there is no current draft yet, but there's three of us working on one, once we get back to work from IETF (-:

so be on the lookout for that, if you care about it

Lovely.

So that's Paris covered?

most people, smarter people, take time off after these

yes

3) Date of next meeting - same time next week?

wfm

wfm

wfm

4) Request from chair

Can someone else minute this please?

will do

Thanks verym uch.

5) AOB?

None here

I'll have them out by tomorrow

nothing more from me

neither here

Marvellous.

Thanks all.

five minutes over (-:

:)

Yeah, sorry.

no, it's perfectly fine

Exactly 30 minutes, but I needed to be poked to start.

fine with me anyway, I've already told the others I'm likely to miss on Wednesdays (-:

MattJ: MAM. We're almost certain to have someone working on it in Swift for GSoC - so a) Where's the spec and b) How's Prosody's support?

a) the spec is either the one currently on matthewwild.co.uk, or the one I haven't finished yet to submit

b) Prosody's support is for the one on matthewwild.co.uk, and I believe it is mostly complete, just inefficient (fine for developing with, not for production)

Zash would know more, since he wrote it

How different is what you're submitting for XEPpification from what's on mw.co.uk?

Not very

OK, cool.

We have to expect some change from Experimental->Draft anyway.

Right, so everything there will work

But I'm adding querying by id too

But if you'd rewritten it, targetting that doc wouldn't be much use.

No, the basics there won't change

"Querying by id" -> "Get me everything since ID X"?

Yes

Cool.

I think I talked to you about this once upon a time

Yes, I said we needed it.

I was trying to avoid giving messages unique ids

But I agree it's a necessary evil

One interesting open question...

Is how the client knows the id of messages it sends

We either solve it so that it does, or it downloads duplicates

at some point

I think this is most important for clients that have dual local-remote history implementations

and since all clients with history do local at the moment... it's important to them

Everything else is simple, but I can't dream up a clean solution to this

I was going to leave it open when I submit the spec, and see if anyone on the list has bright ideas

MattJ: Well, there are beautiful solutions for it that you don't want to consider :)

Such as?

Like just redownloading all messages and ignoring your 'natural' history in favour of what's in MAM.

Sure, that's one solution (no solution at all)

It just feels like a waste of time to me to re-download messages it already has

Of course it is :)

But, I think we can solve this.

Or, rather, not knowing the id of your sent messages isn't the biggest problem here.

What do you think is?

I'm assuming that the case we're trying to solve here is "I want to use MAM to get a full local history cache, given that I have already received all my this-resource messages"

Indeed

And in this case, the big problem is 'filling in' the same history period for which you have a partial history.

Mmm

Now, possibly the thing to do here is to always use carbons.

That is "If you are going to want a complete local history cache, always use carbons.".

That way you can sync from $LAST_ID -> $NOW when you log in, get carbons of everything from then on, and record the last received message id when you log out. Or even have the server send you the last MAM id for a message you've received when you close the stream.

Indeed

What about messages you send? Which carbons doesn't provide atm afaik

It should.

linuxwolf: Ping.

There's not so much point using carbons to get half of every conversation other than the one for the current session :)

??

IIRC, the original thinking was if a specific resource is sending the message, it doesn't need a carbon of it

how about I change § 3.6 to: Carbons clients want to have copies of messages going in /both/ directions for all resources associated with the same user. To that end, messages of type "chat" that are sent from any resource MUST be copied by the sending server to each of the resources that have enabled Carbons.

Do you currently get a copy of every message sent from another resource?

I thought $OTHER_MATT was implying that you didn't (I thought you did).

This is what you need. I don't think you need a duplication of your own outgoings.

No, sorry, I wasn't implying that

When I said "you" I meant the current resource

I don't think you need that, do you?

the current text forwards a <sent/> carbon to every resource OTHER THAN the sending resource

I can see going either way

linuxwolf: Thanks - that's all I think is needed, but Matt might know otherwise.

forwarding to all sending resources makes it more MUC-like

It does. It also potentially makes it *slightly* nicer for local history caching.

that's what I was thinking

But it's pretty slight, I think, and the bandwidth cost isn't insignificant.

true

then again, if you're mobile, you're radio is already at full because you just sent something (-:

and if compression is enabled, how much is that cost really?

just playing devil's advocate here … I'm fine with it as-is, or changing it to every … I don't really care

Right.

I'm happy with as-is, at the moment. I don't think it hurts MAM.

I think having a MAM server send you a "Your last received id is" when you log out would probably be a better solution, if a solution is needed (I'm not convinced it is).

So you think clients should drop local history?

I don't think I'm saying that.

Although I could be wrong :)

I think I'm saying that MAM+Carbons is sufficient already to get a complete local cache.

Or even a local cache where it is incomplete, but the gaps are known.

(And thus could be filled when the user wants history)