[Standards] SHA-1 use in XMPP

Dave Cridland dave at cridland.net
Fri Jun 16 12:33:55 UTC 2017


On 16 June 2017 at 13:02, Jonas Wielicki <jonas at wielicki.name> wrote:
> On Freitag, 16. Juni 2017 12:25:59 CEST Dave Cridland wrote:
>> Folks,
>>
>> Since SHA-1 is considered on the way out, now, it'd be useful to
>> catalogue where it is currently in use, what danger it poses, and what
>> options we have for replacing it - both in terms of protocol
>> considerations and practical concerns of deployments.
>>
>> The current status of SHA-1 is essentially that is is likely to be
>> crackable soon, but only in terms of a long-term effort. So a use of
>> SHA-1 where the attacker would have to preimage/collide it rapidly are
>> less of an issue than cases where an attacker could spend a couple of
>> months over it.
>>
>> As an example:
>>
>> SCRAM-SHA-1 is our current MTI SASL mechanism. It is used to hash
>> long-term credentials. Replacing it would rely on SASL mechanism
>> agility; existing client implementations likely rely on it as the MTI
>> however.
>
> Is the collision thing an actual problem for SCRAM? (Not saying that we should
> not upgrade soon-ish, but still.)
>

Assuming that one could extract the SCRAM hashes while they're still
valid, yes. XMPP lacks a way to require a password change (though I
intend getting that into SASL2), so there's not much mitigation here.

>
>> What else do we have?
>
> Off the top of my head (surprise): Entity Capabilities (XEP-0115).
>

Yes - is there an attack here? And I assume the right solution is to
move to ecaps2 when ready?

> There are quite a few matches for sha1 in the xeps repository; didn’t Tobias
> want to make a survey of the existing XEPs?

Council did indeed want to do a survey, but we've all been busy, so my
solution is to ask the standards list and crowd-source it.

Dave.


More information about the Standards mailing list