XMPP Council - 2012-08-15

T - ~5 minutes

15?

/isgh

yesh

you need last message correction!

I was testing you all

(-:

a use case!

I really really need to spend some quality time with XEP-0301 again

I think there needs to be a lock-down on 301 updates for a week or two

heh

i'm about to set up a filter

'tis time?

indeed

It is.

1) Roll call

MattJ sends apologies.

here

absent

*presente

it's getting old quickly now^Uhaha

Tobias: ?

It's just getting started

yes.here

s/it's just getting started/indeed/

Right.

2) Matt's IETF report.

so

2.1) E2E — still progressing, mostly in JOSE not XMPP directly

by the way, if anyone is interested in a solution here, I would recommend joining the jose@ietf.org mailer and commenting on any non-OpenId use cases

2.2) DNA — Stpeter and I wrote up a series of drafts for domain name associations (formerly assertions)

they are light on examples, and there is desire for more guidelines; which to do first, signaling preferences, etc

also includes prooftypes using DNSSEC/DANE and POSH

POSH being "PKIX over Secure HTTP" -- basically parking your certificate at a well-known URI

thank you

2.3) 6122bis — mostly waiting on PRECIS, but there are some changes to processing order, and what to do with certain classes of code points (e.g. full- and half-width)

to be sure, this is the certificate proving that a host may act for a particular domain, right?

ralphm: yes, by virtue of HTTPS 30x redirects

request https://mydomain.com/.well-known/posh._xmpp-client._tcp.cer , get redirected to https://thathostingcomany.net/.well-known/posh._xmpp-client._tcp.cer

DNSSEC is our existing SRV lookups, but with the expectation the record(s) are signed (valid)

Oh, that's a bit icky isn't it?

Kev: it's not perfect, but it is deployable

Requiring people not just to know how to get to the final resource, but also to keep track of how HTTP panned out getting there, I mean.

Well-known-URIs are themselves icky, but I can hold my nose for that.

most HTTP libraries will let you know when a redirect is followed, and how

Does this allow more than one jump?

that right now is not specified … it could, and we'll probably need to put some limits around it

I've got a feeling of general unease about redirects and proofs, because you need to keep track of cert trust at each hop and blah.

indeed. There have been issues with this in other protocols

Kev: alternate suggestions welcome

Not that this is a deal-breaker, I just enter it with trepidation.

so do most of us

but

it's at least something that could get implemented and deployed before universal IPv6

well, universal DNSSEC

(and DANE)

xmpp:jabber.org has IPv6.

I assert that universal DNSSEC will happen just after universal IPv6

Anyone using HE can't route to it...

Kev: that's not universal

d-:

POSH is one possible approach, DNSSEC/DANE is another

both have the potential to make dialback even more relevant than before

OK. I need to use my time machine to create some more time to look at this better.

Kev: I know exactly what you mean (-:

Was that the IETF report done with?

Kev: go back further and tell those IPv4 people to do it right

ralphm: I think the IPv4 people /did/ do it right.

IPv6 is much more contentious.

re IETF report — there's probably some things happening in PRECIS that are relevant to us also

oh!

Kev: point

http://tools.ietf.org/html/draft-marques-l3vpn-end-system-06

this is a draft for using XMPP pubsub for propagating layer-3 VPN information

+1

Oh, neato.

well, it's a lot of things, but XMPP is in there

they do need some help, though

Maybe this XMPP lark will take off.

HTTP(s) is the One True Protocol™

anyway, I would recommend those enthusiastic about pubsub to read that draft ...

oh collection nodes

… and contact Pedro Marques <roque@contrailsystems.com> with corrections, suggestions, questions, etc

ralphm: yeah, although I don't think they actually need them for what they are doing

m&m: pretty unlikely

Also, anyone interested in end-to-end encryption and signing should pay attention to JOSE

and that is all

Perhaps if I didn't lose the best part of a day to dealing with DDoS attacks I'd have time for this.

*grumble*

OK, thanks Matt.

yeah

3) Date of next meeting.

SBTSBC WFM

We'll have 308's LC ended by next Wednesday, so we should have something to discuss...

/nod

SBTSBC works for me, I think.

WFM

+1

Great.

4) Any other business?

not for me

OK, we're done then.

Thanks all

yes, thanks

gracias

thanks!