Re: [rtcweb] Comments on draft-ietf-rtcweb-security-06

Martin Thomson <martin.thomson@gmail.com> Mon, 24 February 2014 18:58 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCFE1A02B4 for <rtcweb@ietfa.amsl.com>; Mon, 24 Feb 2014 10:58:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level:
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmEaWEcKG5qL for <rtcweb@ietfa.amsl.com>; Mon, 24 Feb 2014 10:58:51 -0800 (PST)
Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5B01A0154 for <rtcweb@ietf.org>; Mon, 24 Feb 2014 10:58:50 -0800 (PST)
Received: by mail-wg0-f50.google.com with SMTP id z12so4953545wgg.17 for <rtcweb@ietf.org>; Mon, 24 Feb 2014 10:58:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zBJtKas5tis1Ukd3UBmVwOT8VvZtNVUvAdWFWUbkGAM=; b=j4kVJNOe6En2vZKJE/HFIZOJ3u2/3hSd+vSsxXDq0Yefir32deb36HLuBd/ivJrwuR N50akj79ldkbPv/UKjafeY4uuo4LFowbfIaeLfLqg9cgkEtXlXGU+Gkjeo8UBUYSiSWb OYBi4WUy4/RNFLNzqcUwmzQOXjKfi/Hn02A3GtECR8KA2I2+lTBNS5DCKQcUHerG/2ZY 5/y1XKiuad16lknOnp4TgFOBwulHIHwxm898jEFJhPuU3Y2JL37IP/fFp2QZPsr6kI6C aR9YVjSVV07sUDVPKeHQZGIVjVvsHUZZL9/wXo3hX+RNqxfnTinjKe8F2cQvxQI4jwyA 8Z6A==
MIME-Version: 1.0
X-Received: by 10.180.84.73 with SMTP id w9mr15643029wiy.58.1393268329984; Mon, 24 Feb 2014 10:58:49 -0800 (PST)
Received: by 10.227.10.196 with HTTP; Mon, 24 Feb 2014 10:58:49 -0800 (PST)
In-Reply-To: <530B194F.4040909@ericsson.com>
References: <530627C7.30906@ericsson.com> <CA+9kkMAMf2qBm4LX3ooPOW3xsBO=LEw045NWDnX3ahWBByaUQQ@mail.gmail.com> <53070996.9040707@ericsson.com> <CA+9kkMAXxx3eP2fuBU7LCtwFwgzRs7+uYpTJAoWYnEdBaTavaQ@mail.gmail.com> <CABkgnnV_SL1gxfDXHVUu1qGho5dUzx2vK4RumSnCq-FH5-zt0g@mail.gmail.com> <530B194F.4040909@ericsson.com>
Date: Mon, 24 Feb 2014 10:58:49 -0800
Message-ID: <CABkgnnXAphLn5uY6WmMYMGRv0j0J3LmSFBAMthcnj2oa-3T9-Q@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/IeIGf8kgC06Qb2Q9R6qrq8eGnm4
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-security-06
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 24 Feb 2014 18:58:52 -0000

On 24 February 2014 02:05, Magnus Westerlund
<magnus.westerlund@ericsson.com> wrote:
> My position is that the above mitigation is unlikely to have significant
> impact on this attack.

That was my sense too.

> There are two reasons I wanted this attack to be considered. First, it
> provides a clear requirement on having congestion control as first level
> mitigation.

Congestion control.  Check.

> Secondly, I think this could become a significant issue as data channel
> PeerConnections can be opened without user consent. A malicious JS that
> is sufficient well spread with a well working find and connect could
> establish a large mesh of peer connections that could come close to
> saturate each endpoints local access link, resulting in very heavy loads
> on the network, even with congestion control. With congestion control
> you can likely prevent congestion collapse, but you should be fully
> capable of driving a network into a state of "mostly useless",
> especially a network suffering from buffer bloat inside of the ingress
> nodes.

So the concern is that even with congestion control, a single bad
actor can use more than their "fair" share of network resources.

Sadly, this is already true on the web.

No harm in writing down the potential.  Are you looking for anything
more than that?