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

"Muthu Arul Mozhi Perumal (mperumal)" <> Tue, 16 July 2013 10:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C076E11E80AE; Tue, 16 Jul 2013 03:49:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.399
X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Qfj1aG5b7bxd; Tue, 16 Jul 2013 03:49:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3E63321E8091; Tue, 16 Jul 2013 03:49:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=6594; q=dns/txt; s=iport; t=1373971750; x=1375181350; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Po4m7Ra9CAvA43jLU366UxgT7gkxW2+ystwk/lVI/Pw=; b=b6mw8HJ6RG/DecOFPmBRKVNGzhf5V7loTsQTSXnRU694P1sdWJAgqlm7 pzEPSPpwSVySXNvGshmZlJ1I+qQLXrDIDgrKNq7xo8F2xIAgwfuysxoTe kpbXplFshrSM2QItDCCaSdNDavsV/ohtp8neskPeFsXwfu4RJl/3BIo7Y M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.89,676,1367971200"; d="scan'208";a="235447897"
Received: from ([]) by with ESMTP; 16 Jul 2013 10:49:08 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r6GAn8nW007407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 10:49:08 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Tue, 16 Jul 2013 05:49:07 -0500
From: "Muthu Arul Mozhi Perumal (mperumal)" <>
To: Simon Perreault <>, "" <>, "" <>
Thread-Topic: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
Thread-Index: AQHOggfD5W/HlPrVS02D/hotnG5s6plnD7Qg
Date: Tue, 16 Jul 2013 10:49:07 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Tue, 16 Jul 2013 10:49:15 -0000

[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 -:). SRTP itself is still being debated in RTCWEB, so nothing is final, yet.

|>    For consent, calculating the SHA1 HMAC is necessary for MESSAGE-
|>    INTEGRITY which is computationally expensive.
|You need to qualify "expensive". It's certainly not expensive in all cases.
|>    Security analysis
|>    concluded that the STUN 96 bits transaction ID is sufficient for
|>    consent, without needing MESSAGE-INTEGRITY.
|What analysis? You would need to explain it in detail. But if that's not
|part of your suggested solution, just remove the sentence.

Agree it could be elaborated. The intention was to say the foll:

   STUN requires the 96 bits transaction ID to be uniformly and randomly
   chosen from the interval 0 .. 2**96-1, and be cryptographically
   random. This should suffice to prevent off path attacks on consent 
   freshness, so MESSAGE-INTEGRITY is not necessary from a security

However, MESSAGE-INTEGRITY is still used to maintain backward compatibility 
with legacy ICE/ICE-lite implementations.

|Now on to section "4. Solution Overview"...
|>    Every Tc seconds, the WebRTC browser sends a STUN Binding Request to
|>    the peer.  This request MUST use a new, cryptographically random
|>    Transaction ID [RFC4086], and is formatted as for an ICE connectivity
|>    check [RFC5245].  A valid STUN Binding Response is also formatted as
|>    for an ICE connectivity check [RFC5245].  The STUN Binding Request
|>    and STUN Binding Response are validated as for an ICE connectivity
|>    check [RFC5245].
|Couldn't this whole paragraph be simplified to "Every Tc seconds, the
|WebRTC browser sends an ICE connectivity check."? Is there anything new
|here besides the "every Tc" thing?

The difference from the ICE connectivity check is that there is no exponential back off for retransmissions.
|>    Liveness timer: If no packets have been received on the local port in
|>    Tr seconds, the WebRTC browser MUST inform the JavaScript that
|>    connectivity has been lost.  The JavaScript application will use this
|>    notification however it desires (e.g., cease transmitting to the
|>    remote peer, provide a notification to the user, etc.).
|This seems to me like it will not fulfill the goal set in the abstract:
|"to ensure that a malicious JavaScript cannot use the browser as a
|platform for launching attacks". If the JavaScript is free to ignore the
|notification from the browser, then it has no security benefits. If you
|want to reach that goal, the browser needs to forcefully stop transmitting.

That goal is fulfilled by the consent checks -- the browser would stop transmitting everything on that candidate pair, including liveness checks, if there is a consent failure.

|>    When not actively sending traffic on a nominated candidate pair,
|>    performing consent freshness does not serve any purpose from a
|>    security perspective.
|I don't understand what this means. Why is the "security perspective"
|important here? Aren't we concerned about keepalives?

You mean one could use keepalives (Binding indications) for launching attacks, so consent freshness would be required for sending them as well?

|>    In ICE [RFC5245] the STUN request/response are protected with
|>    MESSAGE-INTEGRITY, using an ephemeral username and password exchanged
|>    in the SDP ice-ufrag and ice-pwd attributes.  This prevents ICE from
|>    accidentally connecting to an in-intended peer, in that ICE will only
|>    connect to a peer that also knows the same username and password
|>    (exchanged in call signaling).  Once that connection to the remote
|>    peer has been established with ICE, the consent to continue sending
|>    traffic does not benefit from re-asserting that same username and
|>    password, so long as the senders and receiver's IP addresses remain
|>    the same (as they usually do).
|I had not understood from the text that there was no auth stuff in the
|request. The text said "This request [...] is formatted as for an ICE
|connectivity check [RFC5245]." I thought that included auth stuff.
|The explanation why no auth stuff in the request is acceptable should be
|moved to section 3.

Agree, it could be moved under design considerations.


|Behave mailing list