Re: [rtcweb] Consent alternative

Martin Thomson <martin.thomson@gmail.com> Wed, 04 December 2013 18:38 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 5DB291AC862 for <rtcweb@ietfa.amsl.com>; Wed, 4 Dec 2013 10:38:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KizcZ4S1JUdW for <rtcweb@ietfa.amsl.com>; Wed, 4 Dec 2013 10:38:22 -0800 (PST)
Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id C04B41A1EF9 for <rtcweb@ietf.org>; Wed, 4 Dec 2013 10:38:21 -0800 (PST)
Received: by mail-wi0-f174.google.com with SMTP id z2so7160652wiv.7 for <rtcweb@ietf.org>; Wed, 04 Dec 2013 10:38:18 -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=o0Ap4y9RR3XR6NnmIVFy5TESlXMQU3mbxLvgJQP2e5g=; b=0YhxDsotHljCyW1Bv5Mqc6A9YLSrCYAyI3fDT0jbWy7xAsvEeTwVAuzu0lF0ZrJHHb r2I4Cd6vJoYDdSJq8FMN6mTtSeCK95FDRRu8WORMjzO5V2dn3euh7blXUPTC0MWeU0B+ 2cQj8dWvhzOm8XgSPalbd2jdG7rAhp2weJueP6Gn6To6CvUB/g8v4CW+JW43FJ3cm4JQ EBj4DBkoKq0iECy/CtmXwoF+TCwnpLjhFElZPzlUeYub4WXKZJm9hdQfE6EK7Eb02zjV eR0Xed7jqdZB6NQlPx3tydy+Jl7CsQ7OnILY0C2ze6c/0wq2ulrHDFlKP5u10oEOYCcj Rdvg==
MIME-Version: 1.0
X-Received: by 10.194.85.75 with SMTP id f11mr13698056wjz.14.1386182298116; Wed, 04 Dec 2013 10:38:18 -0800 (PST)
Received: by 10.227.134.195 with HTTP; Wed, 4 Dec 2013 10:38:18 -0800 (PST)
In-Reply-To: <E721D8C6A2E1544DB2DEBC313AF54DE224373610@xmb-rcd-x02.cisco.com>
References: <CABkgnnVNnT8uoWM8T=TqbTmy11CGTeHLP=_7z5KSMSpAsp9SyQ@mail.gmail.com> <52989933.6000907@ericsson.com> <CABkgnnUX3OFUyc5PXeN0ydykBwL0HyRuaigfJKMBbuWnuhnVJg@mail.gmail.com> <E721D8C6A2E1544DB2DEBC313AF54DE22436FBD9@xmb-rcd-x02.cisco.com> <CABkgnnUy3HxvsqYfwspEQ9_g1frUuFF4rwD-hTz45UzCr1fTBw@mail.gmail.com> <E721D8C6A2E1544DB2DEBC313AF54DE22437073A@xmb-rcd-x02.cisco.com> <CABkgnnVOuG9pNRA8RzBYOhTHUih0RASchVHxYsnYQk8fDs_VLA@mail.gmail.com> <E721D8C6A2E1544DB2DEBC313AF54DE224373610@xmb-rcd-x02.cisco.com>
Date: Wed, 4 Dec 2013 10:38:18 -0800
Message-ID: <CABkgnnUx_KfRYJ61_ymF_uXLs6o2NXka2gVG1a+K82YWBkF8CA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
Content-Type: text/plain; charset=UTF-8
Cc: "Cullen Jennings \(fluffy\)" <fluffy@cisco.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Consent alternative
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: Wed, 04 Dec 2013 18:38:23 -0000

On 3 December 2013 21:08, Muthu Arul Mozhi Perumal (mperumal)
<mperumal@cisco.com> 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
necessary.