Re: [rtcweb] Consent alternative

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5DB291AC862 for <>; Wed, 4 Dec 2013 10:38:23 -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 KizcZ4S1JUdW for <>; Wed, 4 Dec 2013 10:38:22 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c05::22e]) by (Postfix) with ESMTP id C04B41A1EF9 for <>; Wed, 4 Dec 2013 10:38:21 -0800 (PST)
Received: by with SMTP id z2so7160652wiv.7 for <>; Wed, 04 Dec 2013 10:38:18 -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; bh=o0Ap4y9RR3XR6NnmIVFy5TESlXMQU3mbxLvgJQP2e5g=; b=0YhxDsotHljCyW1Bv5Mqc6A9YLSrCYAyI3fDT0jbWy7xAsvEeTwVAuzu0lF0ZrJHHb r2I4Cd6vJoYDdSJq8FMN6mTtSeCK95FDRRu8WORMjzO5V2dn3euh7blXUPTC0MWeU0B+ 2cQj8dWvhzOm8XgSPalbd2jdG7rAhp2weJueP6Gn6To6CvUB/g8v4CW+JW43FJ3cm4JQ EBj4DBkoKq0iECy/CtmXwoF+TCwnpLjhFElZPzlUeYub4WXKZJm9hdQfE6EK7Eb02zjV eR0Xed7jqdZB6NQlPx3tydy+Jl7CsQ7OnILY0C2ze6c/0wq2ulrHDFlKP5u10oEOYCcj Rdvg==
MIME-Version: 1.0
X-Received: by with SMTP id f11mr13698056wjz.14.1386182298116; Wed, 04 Dec 2013 10:38:18 -0800 (PST)
Received: by with HTTP; Wed, 4 Dec 2013 10:38:18 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Date: Wed, 04 Dec 2013 10:38:18 -0800
Message-ID: <>
From: Martin Thomson <>
To: "Muthu Arul Mozhi Perumal (mperumal)" <>
Content-Type: text/plain; charset="UTF-8"
Cc: "Cullen Jennings (fluffy)" <>, "" <>
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:38:23 -0000

On 3 December 2013 21:08, Muthu Arul Mozhi Perumal (mperumal)
<> wrote:
> |I think that you have missed the point here. The point is that A and
> |B share a DTLS connection, and B uses ICE to convince A to send
> |packets for that connection to C.
> Can you describe that in terms of a real-world use case? I don't see how that is different from a 3PCC scenario where the 3PCC (e.g a call center agent) talks to both A and C, and transfers A to C (aka full-consult transfer).

I'm not describing a use case, I'm describing an attack.  A 3PCC
transfer should result in a new DTLS connection.  That's a completely
different scenario.

> |All this requires is that B is able to spoof the source address of
> |packets to appear as coming from C.
> B doesn't have to spoof anything at all -- for the ICE connectivity check to succeed b/w A and C, B just needs to send A's ice-ufrag and ice-pwd to C and vice versa.

Yes, B does have to spoof something.  If B's goal is to cause A to
send packets to C without consent from C (or, more precisely, even
when C initially consents, then ceases to consent), then spoofing is