XMPP Council - 2017-01-25

I figured I should show up for this council meeting since you'll be discussing advancing XEP-0368, I'll just stay quiet unless someone highlights me :)

seems it's about time

1) Roll call

here

Here, but not be for long.

(Daughter has a doctor's appt)

Link Mauve, SamWhited?

maybe they'll join later

2) Minute taker

I offer to do it, if nobody else wants

I’m here.

i was just about to say that it's my turn again. but I can do it next time

oh no actually I can't because i'm probably going to be on a train to brussels

ok..last week we didn't clearly indicate that we wanted to vote on things..so here explitily again

3) Voting to Advance XEP-0333 to Last Call

Sorry, here

+1

+1

+1

+1

Dave Cridland, still there?

Yes, sorry. +1.

perfect

4) Voting to Advance XEP-0233 to Last Call

+1

on list

+1.

Still confused as to why Mili Verma's not listed as an author, mind.

On list too, I started reading the referenced specifications but I still don’t grasp all of the mechanisms there.

+1; Mind you, I don't feel that I have enough knowledge of Kerberos to know if this is a valid way to do things, or if it's used anywhere or if there have been deployment issues, etc. but I figure that's what LC is for.

SamWhited, Mili's edits basically were in response to developing this on WIndows and UNIX.

SamWhited, So I think it's well past ready.

5) Voting on moving XEP-0368 forward (issuing LC)

+1

+1

+1

+1

+1

6) Short update on XEP-0300 fixing

I've updated XEP-0300 https://github.com/xsf/xeps/commit/2f21fbef22d484d1651596aeb279b3386398c183 would be nice if people could give a quick overview sometime if they see issues with that, if not we can issue an LC to move that to draft in a couple weeks

7) Voting on moving 2010 compliance suites to obsolete to prevent confusion while we work on the 2017 ones

+1

+1

+1

for background, I plan on writing the 2017 ones on the flight to Brussels and withdrawing the 2016 ones

I’ve read it earlier, I was wondering whether making sha3-256 and blake2b-256 mandatory is that sensible before every crypto library is well updated to support them.

Re: 6)

Tobias, +1.

Tobias, also obsoleting the 2012 ones.

-0

Oh are there 2012 ones too? Yah, +1 to obsoleting both of them.

I don't really care, but I'm not sure it's worth the effort.

But absolutely not a hill for me to die on.

Link Mauve, something for the next meeting to vote on then...don't want the topics/voting issues to change mid-meeting, especially not mid-voting

Sure.

8) Date of next

Does next week work for everyone, or do we want to skip a week?

I won’t be here next week, I’ll be on the train to Brussels.

I'm not here next week.

i have to check my train schedule again. but i'm fairly certain i'm on a train at 1600Z

We could have a small impromptu meeting a little bit later in the day next week

I'll be driving to Bristol. To take a plane to Amsterdam. To take a train to Brussels.

Or on the 2nd

right, so it'll probably make sense to skip a week

How many of us are in Brussels on Thursday?

either move it back a couple of hours or skip it

Thursdays yes. also wednesday

Dave Cridland, i guess everyone

We have had a Council meeting in the Summit before, could be fun to do again - might get someone else to take minutes.

Finally! \o/

Find a pub and rope someone in to take minutes with the promise that I'll buy them a beer :)

sure..so sometime thursdays next week?

Wfm.

yes

great...even if we fail to arrange it, there'll still be a week afterwards :)

9) AOB

doesn't look like it

Thanks!

thanks everyone

thank you

Thank you.

Tobias: RE 0300, I had the same thought as Link Mauve — how wide spread is sha3? I know the Go standard library has an implementation, but it tends to be ahead of other things. Eg. does Java have one? I don't think Rust does yet (not that that's very relavant, but it's the only other thing I really pay attention too)

Link Mauve, what environments do you know of with bad sha3 support?

None actually, but probably older openssl don’t have it yet.

for anything C/C++ related it's probably a little issue as there's ready to use reference impementation code for sha3 and blake

Does stable Debian OpenSSL?

OpenSSL doesn't

There's code, but it's not exposed

recent openssl has blake, they should have sha3 too, not?

Oh hey, I lied, Rust has sha3 in the standard library already.

bouncycastle also has SHA3

or rather, it has an implementation already.

OpenSSL apparently still doesn’t have it, according to https://github.com/openssl/openssl/issues/439

Personally I think it would be good to leave it as a SHOULD at least until OpenSSL has it.

Oracle Java seems to have it since, earlier this month https://bugs.openjdk.java.net/browse/JDK-8004078 ^^

There's a keccak1600.c in the sources, however it's not used by anything

daniel, any information about Android?

Link Mauve, not from the top of my head

If bouncy castle has it would it not work on Android?

SamWhited, if bc has it everything is fine

Ok.

Fyi, Python got both sha3 and blake2 only in 3.6.

also the idea was having multiple algorithms set to MUST, so implementations strive to support as many of the MUST ones as possible...the it's more likely that there is matching support between two entities

I’m not against it, I was just wondering whether it wouldn’t be a bit too early.

Link Mauve, considering how rarely we seem to have updated XEP-0300 the idea was to make it more future proof :) but happy either way...but we should at least aggree on it before voting on it to LC

Hmm, I could go either way now. Future proof sounds good; I wouldn't want to block either way.

Same, I’m fine with LC as is.

Isn't there some RFC / BCP you can point to for recommendations, so we don't need to update it as best practices change?

great...also added a table for the textual names of the new hashes...IANA is a bit slow there, as their table was last updated 2006

Zash, i don't know of one

Zash, I imagine the TLS spec has hash recommendations

Zash, then again, RFCs don't get updated..only replaced by other RFCs