Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
Simon Perreault <simon.perreault@viagenie.ca> Tue, 16 July 2013 12:04 UTC
Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6794821E805F; Tue, 16 Jul 2013 05:04:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.526
X-Spam-Level:
X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kr0OM1chKled; Tue, 16 Jul 2013 05:04:20 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 06B3711E80D7; Tue, 16 Jul 2013 05:04:17 -0700 (PDT)
Received: from [127.0.0.1] (h228.viagenie.ca [206.123.31.228]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A197B470FB; Tue, 16 Jul 2013 08:04:15 -0400 (EDT)
Message-ID: <51E536C1.1080507@viagenie.ca>
Date: Tue, 16 Jul 2013 14:04:17 +0200
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <E721D8C6A2E1544DB2DEBC313AF54DE224198182@xmb-rcd-x02.cisco.com> <51E513BF.2040405@viagenie.ca> <E721D8C6A2E1544DB2DEBC313AF54DE224199A15@xmb-rcd-x02.cisco.com>
In-Reply-To: <E721D8C6A2E1544DB2DEBC313AF54DE224199A15@xmb-rcd-x02.cisco.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "behave@ietf.org" <behave@ietf.org>
Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jul 2013 12:04:21 -0000
Le 2013-07-16 12:49, Muthu Arul Mozhi Perumal (mperumal) a écrit : > |> 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.. Ok, then s/but/and/. > |> 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 -:). SRTP itself is still being debated in RTCWEB, so nothing is final, yet. Ok, then say so in the draft. > |> 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 > perspective. > > However, MESSAGE-INTEGRITY is still used to maintain backward compatibility > with legacy ICE/ICE-lite implementations. Ok, then say so in the draft. > |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. Ok, then say so in the draft. > |> 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. That's not what the draft says. It says that the browser "notifies" the JS app. It needs to say that the browser MUST stop sending. > |> 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? No. This is a section about keepalives. I just don't understand this sentence, and I don't understand why it talks about security. Simon
- [rtcweb] FW: I-D Action: draft-muthu-behave-conse… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Simon Perreault
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Simon Perreault
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Avasarala, Ranjit (NSN - IN/Bangalore)
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Avasarala, Ranjit (NSN - IN/Bangalore)
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Eric Rescorla
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Avasarala, Ranjit (NSN - IN/Bangalore)
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Simon Perreault
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Eric Rescorla
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Avasarala, Ranjit (NSN - IN/Bangalore)
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Avasarala, Ranjit (NSN - IN/Bangalore)