On 23 February 2017 at 20:57, Florian Schmaus <[email protected]> wrote: > On 23.02.2017 18:19, Dave Cridland wrote: >> On 23 February 2017 at 16:53, Florian Schmaus <[email protected]> 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 [1], 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. Dave. _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
