Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)

[Cullen Jennings <[e-mail]>]

> On May 16, 2019, at 8:11 AM, Magnus Westerlund <[e-mail]> wrote:
> 
> Hi Cullen,
> 
> On 2019-05-16 08:21, Cullen Jennings wrote:
>> 
>>> On May 14, 2019, at 3:15 PM, Magnus Westerlund via Datatracker <[e-mail]> wrote:
>>> 
>>> 
>>> A significant security vunerability in PERC that should be made more explicit
>>> and is totally missing is the risks with compromised endpoints. Beyond the very
>>> evident thing that this endpoint can decrypt all media it receives there are
>>> far more sinister risk here. Namely the potential for injection of media that
>>> attempts to impersonate another endpoints media stream. Most of SRTP's cipher
>>> suits only use symmetric crypto functions, thus enabling anyone with the key to
>>> send a packet with any SSRC, and have that being accepted as that source. Where
>>> it is has no practical usage in point to point communication, in conferencing
>>> it becomes an issue. It allows the usage of media level replay or deep fakes to
>>> be used to create media streams that are injected into the media distributors
>>> using an SSRC of another endpoint.
>>> 
>>> The mitiagations that are missing from this document. The fact that a media
>>> distributor that is not compromised or collaborating with the compromised
>>> endpoint could actually prevent such media injection by applying source
>>> filtering of SSRCs and drop all that aren't associated with the endpoint. The
>>> other potential mitigation is to introduce another cipher suit that uses a non
>>> symmetric integrity protection mechanism, such as TESLA to prevent this type of
>>> injection.
>> And the related issue that the main way this can happen is attacker manipulation of the fingerprint so the providing ways to protect that along with SSRC based signalling or TELSA  is the obvious solution space to this. And just to frame the discussion, let me point out the issue you raise is not so much about an SSRC but binding the identity of a member of the group to the audio received. 
> 
> Yes, agree that the fundamental is to know which identity that create a
> particular packet. How that is accomplished there are many solutions.
> 
> 
>> 
>> As other have pointed out, which member inside the conference the media is from is not something PERC provides any information about. Many existing conference systems have existing approaches to solve this problem and they can add PERC as a tool with out breaking theses so it to be specified here. Something that used TESLA could work fine with PERC as well. I do think future work can look at what we need for rosters and active speakers and how to use things like STIR and fingerprints and SDP to tie identity to the media. However, I think that problem is fairly separable from the issue of making sure the operator of the media switch does not have access to the media content. 
> 
> Yes, and to be clear I don't expect that base PERC solution should solve
> the issue. I only requested that the security properties that exist are
> made clear. 

Yes, I agree with you that needs to be clear in the security section that PERC does not solve this. It’s a desirable property of a conferencing system so it would be bad if people expected it to be there. 

> 
> Regarding your below questions I will reply to that separately and it
> may take me a couple of days.
> 

No problem, I totally understand theses things take some time to sort out. Thank you for looking into it. 

> Cheers
> 
> Magnus
>