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

Hi,

And, from a security perspective (the backward compatibility is a separate issue) the requirement to integrity protect the STUN binding requests are not affected by the SDES decision?

Regards,

Christer

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: 9. syyskuuta 2013 15:28
To: rtcweb@ietf.org
Subject: [rtcweb] Consent freshness in the light of no-SDES (Re: Adopting draft-muthu-behave-consent-freshness?)

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.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb