Re: [Perc] Last Call: <draft-ietf-perc-private-media-framework-08.txt> (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard

[Bernard Aboba <[e-mail]>]

On Feb 13, 2019, at 3:47 PM, Sergio Garcia Murillo <[e-mail]> wrote:
> All SFUs I am aware of performs SSRC rewriting, it is much more than implementation convenience.
> 
[BA] In particular, reusing an SSRC for the “dominant speaker” (which can change)  is a common practice with switching of audio and video going together. 
> Also note that we have solved this in one of our deployments using PERC lite allowing ssrc rewriting and app key management, using a different ssrc for the OHB payload used for inner encryption and the outer/HBH rtp packet. The inner/OHB ssrc(=participant Id) is then assigned by the key management server together with the encryption key for each participant so it can be used for mapping ssrcs to participants and allows verifying the origin of a packet end to end.
> 
[BA] This solves the key identification issue, and can also be used to notify participants that the origin has changed if that is a concern.  This potential solution was pointed out during the discussion as I recall.

Far more serious than splicing attacks is access to cleartext media which thanks to ML can be used to create realistic “fake news”.  PERC does not address that threat, but schemes with stricter trust models might.