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