dave at cridland.net
Thu Feb 23 21:36:57 UTC 2017
On 23 February 2017 at 20:57, Florian Schmaus <flo at geekplace.eu> wrote:
> On 23.02.2017 18:19, Dave Cridland wrote:
>> On 23 February 2017 at 16:53, Florian Schmaus <flo at geekplace.eu> wrote:
>>> On 23.02.2017 15:36, Florian Schmaus wrote:
>>>> On 23.02.2017 15:19, Peter Waher wrote:
>>>>> Hello all.
>>>>> SHA-1 is used in many places throughout XMPP. Examples include
>>>>> authentication mechanisms (SCRAM-SHA-1) and entity capabilities
>>>>> (XEP-0115), for instance. Concerning the recent report about
>>>>> vulnerabilities found in SHA-1, should there be an effort to upgrade all
>>>>> these to SHA-256 or later?
>>>> But it may be sensible to change the mandatory hash algorithm of
>>>> XEP-0155. And after we decided a successor of SHA-1 for XEP-0115 we
>>>> could also fix the existing flaws of XEP-0115 like , because this
>>>> would require a namespace bump anyway.
>>> Correction. After having another look at XEP-0115, I don't think a
>>> namespace bump is required. Implementations may simply add (another)
>>> <c/> with hash='sha-256'. I do wonder if we shouldn't simply update the
>>> examples in XEP-0115 so that they say "hash='sha-256'".
>> No namespace bump, true, but it's still a compatibility break.
> Is it a compatibility break? Implementations could send both, i.e., <c
> hash='sha1'/> and <c hash='sha-256'/> for a while and process the "best"
> <c/> when receiving.
Ultimately, we need to stop using SHA-1, not simply start using some
other hash. That is a compatibility break.
I agree we can upgrade over time; in fact we can spend a couple of
years over it most likely, and have the old and new co-exist. But
since it doesn't make much difference if we choose to simply change
hash, or if we choose to change the underlying protocol (at least if
it's a small change), we may as well do any housekeeping on those
protocols we can.
Again, we're totally safe from any weaknesses in SHA-1 for - probably - years.
But since we have to change, we may as well both fix any weaknesses
beyond just hashes, and we might also want to have "MUST accept SHA-3
and SHAKE, MAY send either" or something, to give us a fallback.
More information about the Standards