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

[Roman Shpount <[e-mail]>]

On Wed, Apr 29, 2026 at 1:23 PM Philipp Hancke <
[e-mail]> wrote:

> Am Mi., 29. Apr. 2026 um 18:32 Uhr schrieb Roman Shpount <
> [e-mail]>:
>
>> On Wed, Apr 29, 2026 at 12:20 PM Roman Shpount <[e-mail]> wrote:
>>
>>> 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.
>>>
>>
>> I meant to say the details of the MESSAGE-INTEGRITY-SHA256 implementation
>> were NOT fully considered.
>>
>
> Heh! I assume the RFC is not fixable as an error but requires an update?
>
> The downgrade attack argument is good (applies to most hash agility plans
> I have seen though?) but if we need an ice-option or url parameter anyway
> it goes away.
> This reduces the concern about increasing overhead on initial messages
> requests would have to include both variants (4+20 plus 4 + 32) so we are
> only increasing packet size by 12 bytes?
>
> Thanks Roman for helping me think!
>

I think we can write a new RFC that defines an ice-option
for MESSAGE-INTEGRITY-SHA256. This will define a new STUN usage and will
allow us to define when MESSAGE-INTEGRITY-SHA256 is used instead of
MESSAGE-INTEGRITY without changing RFC 8489.

We will also need an RFC 7065 update to define a new TURN URL parameter to
enable SHA256.
_____________
Roman Shpount