About Hmac-Sha256 Encode password Support.

[DDreame]

hi,
I apologize for bothering you again, but I've become curious about HMAC-SHA1.

While researching, I noticed that RFC8489 mentions SHA256 in section 14.6.

This project currently uses HMAC-SHA1 for encryption, and I'm wondering if there's any consideration for optionally supporting HMAC-SHA256? Additionally, if we were to support HMAC-SHA256, would the clients also need to be adapted (for example, if I want to use webrtc-rs)? If I want to learn more about this, which documentation should I refer to?

This isn't a PR request, but rather more focused on learning and understanding all process in webrtc. If SHA256 support is necessary, I would be happy to add SHA256-related code under guidance.

[DDreame]

ps: These issues are due to our company's strict safety requirements, i am so sorry.

[mycrl]

It doesn't matter, the need to support sha256 is actually quite vague. the message digest attribute of sha256 is actually very little used at the moment, which is why I didn't implement it. I haven't encountered any clients that actively use sha256 yet, they all use sha1.

Another reason is that the biggest use case for turn servers is webrtc. webrtc transfers data that is already very well encrypted, and turn transfers the encrypted data of webrtc. That's why I've been putting my request for transport layer encryption for turn-rs on hold, because it's not a necessary feature that has a large impact on security.

OK, now go back the sha256 digest of the message. In fact, using sha256 message digests doesn't really add much to security at this point, since it's the mechanism used to verify that the message hasn't been tampered with. Now bring in the webrtc scenario, if the message has been tampered with, turn-rs if it can not be effectively found, then webrtc will also be found.

But I don't deny that this can be supported and can be treated as a feature request, I'll schedule a later iteration to include it.

If your company has higher requirements for security, I would suggest focusing on webrtc itself, turn servers are actually less important requirements, that's my opinion.

[DDreame]

Great! I understand the MESSAGE-INTEGRITY-256.
More one question: ICE username and password look like are same encode function as hamc-sha1. So is it same as stun that hmac-sha1 and hamc-sha256 on the turn and ice.

[mycrl]

STUN and TURN are the same, but ICE I'm not so sure about, turn-rs doesn't support ICE related features, I haven't looked into it yet.

[mycrl]

There are so few clients that support Hmac-Sha256 that if I implement this feature, it will only be up to me to test if it works.

(It's a black hole for me to test my own stuff to see if it works, and in a situation where I don't know if there are problems with the implementation either.

Lower the priority of feature requests.