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

[Eric Rescorla <[e-mail]>]

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