[AVTCORE] Re: STUN SHA-256 usage in WebRTC (ICE and TURN)

[Roman Shpount <[e-mail]>]

It looks like the details of the MESSAGE-INTEGRITY-SHA256 implementation
were fully considered. What is described in RFC 8489 is counterproductive.
If MESSAGE-INTEGRITY-SHA256 is comprehension-required, including
MESSAGE-INTEGRITY also makes STUN messages less secure. It should have been
in the comprehension-optional range.

You should also consider the increase in STUN message size. Adding
optional MESSAGE-INTEGRITY-SHA256 will result in an extra 32 bytes in each
STUN request.
_____________
Roman Shpount


On Wed, Apr 29, 2026 at 3:02 AM Philipp Hancke <philipp.hancke=
[e-mail]> wrote:

> (cross-posting between tsvwg and avtcore, we need to decide where it fits)
>
> I recently looked into making WebRTC support sha256 message integrity for
> STUN/ICE
> My assumption was that this would be fairly trivial, send both sha-1 and
> sha-256 MI attributes, pick the stronger one after initial responses.
> Which is what
>   https://www.rfc-editor.org/rfc/rfc5389.html#section-16.3
> describes.
>
> However, RFC 8489 which specifies MI-256
>   https://www.rfc-editor.org/rfc/rfc8489#section-14.6
> uses an attribute type 0x1c in the comprehension-required range
>   https://www.rfc-editor.org/rfc/rfc8489#section-18.3.2
> which means the sender can not send the attribute to "discover" (without
> risking a rejection and another round trip; nobdy likes round trips)
>
> Specifying an ice-option for this seems like a possible solution but I did
> not see any attempt of describing one in the IANA registry:
>   https://www.iana.org/assignments/ice/ice.xhtml
>
> I think the same problem applies to TURN. For WebRTC the solution might be
> to add a parameter to the TURN url
>
> Thoughts?
>
> Philipp
> _______________________________________________
> Audio/Video Transport Core Maintenance
> To unsubscribe send an email to [e-mail]
>