[rtcweb] Consent freshness in the light of no-SDES (Re: Adopting draft-muthu-behave-consent-freshness?)

[Harald Alvestrand <[e-mail]>]

Changing the subject line to make life simpler for those who count the 
respondents :-)

On 09/09/2013 02:20 PM, Christer Holmberg wrote:
> Hi,
>
> I don't object adoption, but a question for clarification.
>
> The draft says:
>
>     "While a WebRTC browser could verify whether the peer continues to
>     send SRTCP reports before sending traffic to the peer, the usage of
>     SRTCP together with Security Descriptions [RFC4568] requires exposing
>     the media keys to the JavaScript and renders SRTCP unsuitable for
>     consent freshness."
>
> Now, as we have decided to not use SDES, I guess that can be removed.
>
> But, based on that, I'd just like to verify whether there is still a need for the draft :)
>

Personal opinion: I think SRTCP is still unsuitable for consent 
freshness. One reason (apart from any aspect that deals with security, 
on which I don't want to comment) is that if one sets up a connection 
with only a data channel, there will be no SSRCs to send SRTCP on.