XMPP Council - 2016-05-17

SamWhited: Shouldn't that be 2016 instead 2015 in xep45?

https://github.com/tfar/xeps/commit/7be5da2654d55d453e1020f5c45ef92a550db222 opinions on it before i send it to the editor?

Tobias: you should use &tobias; ?

however that entity uses my private contact data :)

(and probably update xep.ent)

Tobias, I don't really think we should be introducing new algorithms even at SHOULD, let alone MUST.

MUST could be a bit extreme yeah...but MAY would be too light I think

I also expected some new text at the descriptions of MD5 and SHA1 to reflect the changes in that table.

Introducing a new MUST declares every implementation non-conformant. Introducing a new SHOULD means every implementation is not strictly conformant. MAY is "entirely optional", but we can - relatively easily - introduce at MAY and note that this is expected to increase to a HSOULD or MUST in a review in 6 months.

ralphm, ok..will add those

Or even a SHOULD.

I would SHOULD, I think, if this is the right direction.

MUST seems inappropriate in the absense of a blazing fire.

well..we sure want to encourage people to support SHA-2 and SHA-3

Tobias: but what about http://xmpp.org/extensions/xep-0300.html#existing ?

Don't we need to update each of these first?

It seems to me that making SHA-1 a 'MAY' isn't reflecting reality

if we update these first we'll never update xep-0300

Good point

Tobias: I'll wait for your edits in the prose first them

then

"Microsoft,[7] Google[8] and Mozilla[9][10][11] have all announced that their respective browsers will stop accepting SHA-1 SSL certificates by 2017." so we might aswell advise people to slowly move away from it

and yeah...the related XEPs probably will require updates too, but I think they should depend on XEP-0300 and not the other way around

while they rarely actually use XEP-0300 but use a dedicated XML representation

But the prose on SHA-1 already says you shouldn't use it for signing

hashing should still(?) be fine?

https://en.wikipedia.org/wiki/SHA-1#The_SHAppening

I know about this. My question is, again, does that practically impact the use of SHA-1 as is done in our existing extension?

That you want to discourage it for new protocols seems obvious

that's why i suggested MAY for SHA-1 and not SHOULD NOT or MUST NOT

Tobias: we agree here, I am curious about the other protocols referenced in section 8

in the end the XEP is a recommendation anyway...it totally depends on the implementation if, let's say a entity caps implementation based on SHA-256 takes off, or if clients doing jingle ft provide stronger hashes

I get this, but Section 8 provides an analysis about the use of SHA-1 in existing applications and my question is: should that section be updated to reflect the findings of the SHAppening

probably, can't hurt :)

will also add that lataer

will also add that later

I am also curious if anyone is working on an updated CAPS

i don't have it currently on my plate...mostly just 300, a jingle URI and an asynchronous file sharing XEP

jingle ft should be changed to replace the references to sha-1 before making it to draft, probably?

As far as I know, SHA-1 is looking shakey for collisions, but not preimage. MD5 is still immune to preimage too, but it's sufficiently fast that brute forcing is an option in many cases - SHA-1 is headed that way. Interestingly, HMAC used to provide some protection for collisions, but this is also now broken.

Dave Cridland: right. But Jingle FT is still experimental, if we think that SHA-1 will be completely broken soonish, maybe we should start fixing the examples with a different hash function.