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

"Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> Tue, 16 July 2013 12:43 UTC

Return-Path: <mperumal@cisco.com>
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 E032A11E80D7; Tue, 16 Jul 2013 05:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.549
X-Spam-Level:
X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 MNF-AY3tkM+n; Tue, 16 Jul 2013 05:43:27 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1100021F9C4F; Tue, 16 Jul 2013 05:43:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6200; q=dns/txt; s=iport; t=1373978607; x=1375188207; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LsbzuIhIyAnXUeD6G6plhhi4nUlH2PrPe91sDRqnMdg=; b=eC+sK2jLvvpVOT7m/1jFIsYs986ugDmhW10SxPPqruvDl9YN5k/7FkHf 5SQ35oRU9ZLBMKEw5kl48x4/KTLy21Sb7y8MNUv+AuWAuwiDAi+iwp7Pz OQLnSzrhACUceKq1XF3EFF84yIVGdDlO16e5qcV5AkZUtpPpZiramPhGZ Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhgFADs/5VGtJV2b/2dsb2JhbABagwaBA8FdgQ4WdIIjAQEBBHkMBAIBCBEEAQELHQcyFAgBCAIEDgUIE4d1tiaPLjEHBoMGbQOIb6A6gxKBaiQa
X-IronPort-AV: E=Sophos;i="4.89,676,1367971200"; d="scan'208";a="235403631"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 16 Jul 2013 12:43:26 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6GChQrI011223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 12:43:26 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Tue, 16 Jul 2013 07:43:26 -0500
From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: Simon Perreault <simon.perreault@viagenie.ca>
Thread-Topic: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
Thread-Index: AQHOgiIQwKpPGdZXK0Ooeh9Y1O+0Lw==
Date: Tue, 16 Jul 2013 12:43:26 +0000
Message-ID: <E721D8C6A2E1544DB2DEBC313AF54DE224199D69@xmb-rcd-x02.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> <51E536C1.1080507@viagenie.ca>
In-Reply-To: <51E536C1.1080507@viagenie.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.77.66]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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:43:33 -0000

Inline..

|-----Original Message-----
|From: Simon Perreault [mailto:simon.perreault@viagenie.ca]
|Sent: Tuesday, July 16, 2013 5:34 PM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: behave@ietf.org; rtcweb@ietf.org
|Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
|
|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.

No. That section is about liveness check and its intention is just notify the JavaScript of a potential connectivity loss. It is when the consent check fails the browser actually stops sending everything. Does the draft need more text on the distinction between consent and liveness tests?

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

Ok, let me elaborate:
- Consent freshness is not necessary when the browser is not sending any 
  traffic on a candidate pair.
- If the browser is not performing consent freshness on a candidate pair 
  for the above reason, it performs ICE keepalives (or RTP keepalives) to
  refresh NAT bindings.

Of course, the browser could continue performing consent freshness even when it is not sending any other traffic on that candidate pair and skip ICE keepalives.

Muthu

|
|Simon