Re: [rtcweb] Consent alternative

Martin Thomson <> Wed, 04 December 2013 18:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 03DCC1AD8F4 for <>; Wed, 4 Dec 2013 10:59:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rhT1kbsi9kFu for <>; Wed, 4 Dec 2013 10:59:32 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c00::229]) by (Postfix) with ESMTP id 1C5F31AE2D0 for <>; Wed, 4 Dec 2013 10:59:31 -0800 (PST)
Received: by with SMTP id y10so7315075wgg.0 for <>; Wed, 04 Dec 2013 10:59:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZLozuoG/KExFHeuhZ+CLC+mJwfxMFqHNG8DagXhqMgI=; b=W/CrwztwlyiiZmJIRIsxuZ8kHtheX5ih82pqUcd3mZjfzhTXl4IvQjcxiWbIX9j/0m 3fRF0Rd+spU03YdnMBuQlmsnLEY5KMCQUZ1lSE1FyCGIH7CRLEbRS9pxZJsU/244av2j O2c/dNrEsJejGWdtrts89SB1SGw43KzfkFDygRvSDgRIPv0O7zLiGwVWoW3GpnKQyfOj zoHrFM9uAALgZsDbRFwCRUMDIn/0lu5ue5FHvdgRQ6wZDNTbxYXiXCrEt7OR6b96xKBI /JlnRZmQD7VvPM+tZTtA7UWWHyaT3oKQe7Dma+tID5GLDfNpnjV82/EYTuTL+uZyCHSC x9RQ==
MIME-Version: 1.0
X-Received: by with SMTP id p9mr8495906wij.58.1386183568359; Wed, 04 Dec 2013 10:59:28 -0800 (PST)
Received: by with HTTP; Wed, 4 Dec 2013 10:59:28 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Wed, 04 Dec 2013 10:59:28 -0800
Message-ID: <>
From: Martin Thomson <>
To: Dan Wing <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Wed, 04 Dec 2013 18:59:34 -0000

On 3 December 2013 16:24, Dan Wing <> wrote:
> Requiring sending an ICE request (and receiving an ICE response) would also _almost_ work -- that is, when remote party claims to change their IP address not only is an ICE request from their IP address needed, but also need to send an ICE request to their new IP address and get an ICE response (same as you are saying to send them a DTLS heartbeat to their new address).

Yes, almost.  If ICE restart didn't also correspond with a change in
ufrag/pwd it might.  As it stands, ICE restart and new victim look
exactly the same.

> To thwart that, an ICE attacker would need to be on-path and we could envision places where B (the attacker in your enumerated list above) is on a shared network with C (victim), such as shared WiFi.

In general, I find that on-path attackers aren't especially
interesting when it comes to DoS attacks.  Shared WiFi seems like it
might avoid the "directly on path" part, though since the attacker
disadvantages themselves as much as their victim, I don't worry.

> DTLS heartbeat prevents that attack because B (the attacker) doesn't know the necessary secrets to generate the DTLS heartbeat message (whereas with ICE, B would know the ICE username and ICE password).  If I have all that correct for how ICE consent could be attacked, it shows a security advantage of DTLS consent over ICE consent.

Yes.  That is definitely an advantage.