Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt

["Muthu Arul Mozhi Perumal (mperumal)" <[e-mail]>]

|Uh, then how would they be sent to the other side?

Ah, the browser would have to modify the SDP when it is sent on the wire..

|As far as I can tell, with any plausible API SDES requires exposing the keys to JS.

That helps..thanks.

Muthu

From: Eric Rescorla [mailto:[e-mail]]
Sent: Wednesday, July 17, 2013 2:32 PM
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: Simon Perreault; [e-mail]; [e-mail]
Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt



On Tue, Jul 16, 2013 at 6:49 PM, Muthu Arul Mozhi Perumal (mperumal) <[e-mail]<mailto:[e-mail]>> wrote:
[Added rtcweb since I am not sure if everyone involved there are following this discussion in behave]

Thanks for the review. See inline..

|-----Original Message-----
|From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Simon Perreault
|Sent: Tuesday, July 16, 2013 3:05 PM
|To: [e-mail]<mailto:[e-mail]>
|Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
|
|Le 2013-07-15 20:42, Muthu Arul Mozhi Perumal (mperumal) a écrit :
|> The text and the algorithm in the draft are significantly simplified in this updated version.
|>
|> Comments welcome..
|
|MUCH better introduction. Now I feel like I understand the need exactly.
|
|The "Design Considerations" section is still very confusing to me.
|
|>    Though ICE specifies STUN Binding indications to be used for
|>    keepalives, it requires that an agent be prepared to receive
|>    connectivity check as well.  If a connectivity check is received, a
|>    response is generated, but there is no impact on ICE processing, as
|>    described in section 10 of [RFC5245].
|
|...so? Why is "an impact on ICE processing" necessary?

Meant to stress these Binding request/response doesn't trigger an ICE restart..

|
|>    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.
|
|Why does it "require exposing the media keys to the JavaScript"? Is this
|because of a law of nature, or is it because of the way the JavaScript
|API is being designed? Could the JS API be changed to accommodate
|SRTCP+SDES?

That's how the API construct looks like today -- the JavaScript would get an SDP blob from the browser containing the crypto keys used for SDES-SRTP. Of course, the browser could hide those keys by putting a "****" in SDP -:).


Uh, then how would they be sent to the other side?

As far as I can tell, with any plausible API SDES requires exposing the keys to JS.

-Ekr