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

[Eric Rescorla <[e-mail]>]

On Wed, Jul 17, 2013 at 8:47 PM, Muthu Arul Mozhi Perumal (mperumal) <
[e-mail]> wrote:

>  |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..
>

I don't really see how this helps since the server is going to see it and
call tell
the JS (remember, that's where the JS came from).

-Ekr


>
> |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]> 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]] On Behalf
> Of Simon Perreault
> |Sent: Tuesday, July 16, 2013 3:05 PM
> |To: [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****
>
> ** **
>