Re: [rtcweb] Consent alternative

Magnus Westerlund <> Fri, 29 November 2013 13:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0E8021AE029 for <>; Fri, 29 Nov 2013 05:40:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Bw6FYMmoBNt5 for <>; Fri, 29 Nov 2013 05:40:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 72C6D1AD7C2 for <>; Fri, 29 Nov 2013 05:40:07 -0800 (PST)
X-AuditID: c1b4fb25-b7eff8e000000eda-2a-52989934e3ad
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 8E.AF.03802.43998925; Fri, 29 Nov 2013 14:40:05 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.2.328.9; Fri, 29 Nov 2013 14:40:03 +0100
Message-ID: <>
Date: Fri, 29 Nov 2013 14:40:03 +0100
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Martin Thomson <>, "" <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUyM+Jvra7pzBlBBlf+K1p0TGazuHbmH6PF 2n/t7A7MHlN+b2T12DnrLrvHkiU/mQKYo7hsUlJzMstSi/TtErgyrnw8w1rwUqpiwqfJzA2M D0S7GDk5JARMJN59PckMYYtJXLi3nq2LkYtDSOAQo8S1a79YIZzljBKz/ixiBKniFdCW6Nj0 F8hm52ARUJXYpAoSZROwkLj5o5ENxBYVCJa42ruOGaJaUOLkzCcsILaIQIjEkbbprCA2s4Ca xKPLh8FqhAU0Je5cawabLiQQIDHnwTSwGk6BQImX17YD1XAA3SYu0dMYBNGqJzHlagsjhC0v 0bx1NjNEq7ZEQ1MH6wRGoVlINs9C0jILScsCRuZVjOy5iZk56eVGmxiBgXtwy2/VHYx3zokc YpTmYFES5/3w1jlISCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2P3eqbotsXKe3L+8f7xS1fc /HRK7GfTaTtUP4Y+/afGvS4ilMOPdfNmh2d9X2sKK5+2b5vKyZVw+O7tj1l5T8SjZM48+B53 Ksf+3kef2O11jEcOWmY9upWSXuzE+Ctpa5Ddo8/N3FqlpU6Bzu0PVto6Ho0/fYS9cHnmnHO2 0xpdJjFt1frSnqfEUpyRaKjFXFScCABt8x8RKgIAAA==
Cc: Cullen Jennings <>
Subject: Re: [rtcweb] Consent alternative
X-Mailman-Version: 2.1.15
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: Fri, 29 Nov 2013 13:40:10 -0000

On 2013-11-22 18:55, Martin Thomson wrote:
> I know that I've been a fan of consent via ICE, but with the decision
> in Berlin to move to DTLS only, several of us have observed that
> perhaps RFC 6520 might be a better alternative.
> We've put together an exploration of the idea here:
> The best part of this is that it changes the dynamics (for the better,
> I think).  You don't need to send extra packets if you are actively
> using the flow.  That means that 1:1 sessions won't need to spend
> extra cycles or bytes on keeping the session live.
> There are some gotchas for multiparty sessions, but I believe those to
> be manageable.


I have looked briefly on this and wonder if this isn't vulnerable to
active attacks from a attacker (Alice) that likes to use a set of WebRTC
browsers, including (Bob) to generate DDOS traffic towards the target

So Alice has a web-service which see has attracted a user base or
subverted an existing one for her purpose. The users of said web-service
includes Bob.

So Alice gets Bob's browser to establish a PeerConnection with Alice,
establishing an DTLS security context between them. Then using the
regular signaling Alice triggers an ICE reneg, to move the transport
address target for the Alice to Bob PC to become between Bob and
Charlie. This will require that Alice can intercept or spoof binding
requests response to the Bob's binding requests, especially anyone
promoting it for use so that Bob thinks the ICE reneg succeeds with
Charlie's transport address.

When that has happened, Alice can send periodically Bob DTLS messages
with source address spoofed like they come from Charlie's transport
address to maintain consent. Alice also can use the Stats API and the
HTTP/Websocket connection to Alice web service to forge DTLS protected
RTCP report block messages for the traffic Bob sends to Charlie.

Comparing the ICE based mechanism and the DTLS based consent mechanisms
I would draw the following conclusions.

1. If one doesn't have any chance to intercept STUN binding requests at
all, they are equally secure.

2. If the attacker has some limited or very expensive method for
intercepting Bob's STUN binding requests, then he might be able to mount
the above attack using DTLS consent as he only needs interception
initially when moving Bob to the target, compared to continuously as
long as he like to maintain the attack using the ICE based method.

Cases when this might apply is when Bob are in a poorly protected shared
network and Alice or Alice agent likes to leave the network after having
initiated the attack, rather than have to remain.

This change of properties is due to that the consent is associated with
the DTLS connections security context, rather than constant return
routability with random token property that ICE has.


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: