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

"Muthu Arul Mozhi Perumal (mperumal)" <> Wed, 17 July 2013 12:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9056521F9F1F; Wed, 17 Jul 2013 05:47:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dpwx76Zv98hK; Wed, 17 Jul 2013 05:47:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 100C121F93F3; Wed, 17 Jul 2013 05:47:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=10713; q=dns/txt; s=iport; t=1374065224; x=1375274824; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=acefHav8uesKiFqyNunNL1n1Q7yunoMBUteqB8MR/3Q=; b=gGLLWJbHrMKl6YuA509eqwLvslbAzPuXas3EcX0PcKZ02UoxIt/b97Co vHG2uKxELYd6avK8D0u2FwY5tIb6o/PqMbO9VXAX9XHYyWcFa0m+tXTUf /lP5XuR9tgcrTe8nWqqZ6Xgh4fqBA98ieP1zLXJKcShWTMlYJ7tjFBtV4 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="4.89,684,1367971200"; d="scan'208,217"; a="235907664"
Received: from ([]) by with ESMTP; 17 Jul 2013 12:47:03 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r6HCl334027265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 12:47:03 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 07:47:02 -0500
From: "Muthu Arul Mozhi Perumal (mperumal)" <>
To: Eric Rescorla <>
Thread-Topic: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
Thread-Index: AQHOguu8ib6iXKrxjkSuS/iDhawvUw==
Date: Wed, 17 Jul 2013 12:47:02 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_E721D8C6A2E1544DB2DEBC313AF54DE22419C35Dxmbrcdx02ciscoc_"
MIME-Version: 1.0
Cc: "" <>, "" <>
Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 Jul 2013 12:47:11 -0000

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


From: Eric Rescorla []
Sent: Wednesday, July 17, 2013 2:32 PM
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: Simon Perreault;;
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) <<>> 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:<> [<>] On Behalf Of Simon Perreault
|Sent: Tuesday, July 16, 2013 3:05 PM
|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].
| 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

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.